Method and System for Securing a Blockchain with Proof-of-Transactions

ABSTRACT

Novel tools and techniques are provided for implementing blockchain transactions, and, more particularly, to methods, systems, and apparatuses for securing a blockchain with proof-of-transactions. In various embodiments, the blockchain system utilizes a proof-of-transactions approach that is based on a multi-player voting system and that is not susceptible to a free-rider problem that affects many other cryptocurrencies. The proof-of-transactions approach allows the cryptocurrency network to divide revenue between the nodes in the peer-to-peer network that provides bandwidth and connectivity and a set of other nodes that solve computational puzzles that safeguard the security of the blockchain system.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is a divisional application of U.S. patent applicationSer. No. 16/052,944 (the “'944 Application”), filed Aug. 2, 2018 byDavid Begor Lancashire (attorney docket no. 1059.02), entitled, “Methodand System for Securing a Blockchain with Proof-of-Transactions,” whichclaims priority to U.S. patent application Ser. No. 62/541,657 (the“'657 Application”), filed Aug. 5, 2017 by David Begor Lancashire(attorney docket no. 1059.01PR), entitled, “Method to Secure aBlockchain with Proof-of-Transactions,” the disclosures of which areincorporated herein by reference in their entirety for all purposes.

This application may be related to U.S. patent application Ser. No.16/052,912 (the “'912 Application”), filed Aug. 2, 2018 by David BegorLancashire et al. (attorney docket no. 1059.01), entitled, “Method andSystem for Securing a Blockchain with Proof-of-Transactions” and U.S.patent application Ser. No. 16/052,974 (the “'974 Application”), filedAug. 2, 2018 by David Begor Lancashire (attorney docket no. 1059.03),entitled, “Method and System for Securing a Blockchain withProof-of-Transactions,” each of which also claims priority to the '657Application.

The respective disclosures of these applications/patents (which thisdocument refers to collectively as the “Related Applications”) areincorporated herein by reference in their entirety for all purposes.

COPYRIGHT STATEMENT

A portion of the disclosure of this patent document contains materialthat is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure as it appears in the Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever.

FIELD

The present disclosure relates, in general, to methods, systems, andapparatuses for implementing blockchain transactions, and, moreparticularly, to methods, systems, and apparatuses for securing ablockchain with proof-of-transactions.

BACKGROUND

After the release of the Bitcoin software in 2011, many of the earlyapplications that adopted the network (i.e., SatoshiDice) used bitcoinless as a pure payments service, and more as an open-access messaginglayer that could persist in the absence of centralised managementthrough the distribution of transaction fees to participants in thenetwork. These early applications would often send and receive paymentswith their users, but many would also use the blockchain to broadcastnon-payment information across the network, typically injecting suchinformation into transactions in surreptitious ways, one such way beingthe encoding of human-readable information into false addresses to whichminuscule and unspendable amounts of bitcoin were sent (which may bereferred to as “dust transactions”).

The desire of many developers to use the Bitcoin network as anopen-access and uncensorable messaging platform eventually drove theminto conflict with other developers who were focused on making Bitcoin amore mainstream digital currency, with the conflict between the twocamps arising over the fact that the Bitcoin blockchain compiles everytransaction ever sent into a permanent ledger that needs to be stored inperpetuity by many of the nodes in the network. Since applications thatadded non-payment information to transactions forced this data to beadded to the Bitcoin blockchain, and since this blockchain needs to bestored by most nodes in the system in perpetuity, messaging applicationsincreased the costs of running nodes in the network much more than didpayment-focused applications.

In short time, it became clear that the growth of the blockchain wasposing an economic problem that threatened to undermine the network. Asthe size of the blockchain grew, developers feared that the risingbandwidth and storage requirements for running a full copy of theBitcoin software would result in many nodes in the peer-to-peer networkeventually shutting down, something that would hurt the decentralizationof the Bitcoin network. The problem in essence came about because ofBitcoin's proof-of-work security system, which directed all of therevenue generated by the system to a special class of nodes called“miners” who secured the network from attack but did not need tocontribute significant amounts of bandwidth or connectivity to thepeer-to-peer network to do so. In economics, this is known as a“free-rider” problem as the “miners” were able to “free-ride” on apeer-to-peer network provided by other actors: they could sourcetransactions from the network and use it to generate income, but did notneed to contribute commensurate revenue to support the peer-to-peernetwork themselves, and in fact would work to undermine it by fundingprivate, competing channels for transaction and block distribution suchas the Bitcoin FIBRE network.

As a result, to help keep the costs of running nodes in the peer-to-peernetwork reasonably low and thus preserve the decentralization of thenetwork, many core Bitcoin developers began a rearguard campaign againstthe inclusion of non-payment information in Bitcoin transactions, withprominent developers first labelling applications that persisted inwriting such information to the blockchain as “spam” and then embracinga strategy to cripple Bitcoin's on-chain transaction capacity in orderto drive up the fees that transactions would need to pay for inclusionand thus drive these “messaging” transactions off the network throughprice pressure. In some cases, this conflict even led to vocaldisagreements in the Bitcoin community over such reasonably trivialthings as the question of whether transactions should support a 40 or80-byte user-editable OP_RETURN field.

As alternatives to Bitcoin have emerged in recent years, this problemhas gone unaddressed. While there have been efforts to replace Bitcoin'sproof-of-work system, none has been developed which satisfactorilysolves this “free rider” problem. One of the more well-knownalternatives to proof-of-work is being developed by the Ethereum™Network, for instance, which calls its new approach a proof-of-stakesystem. While this new security method avoids the need for computers toburn electricity to secure the network, its security function does notsolve the “free rider” problem described above: the economic issue offull node under-provision that happens because miners/stakers (the nodesthat provide security against various forms of attack on the network)are paid out of transaction fees while nodes in the peer-to-peer network(which provide bandwidth and open access) are expected to operate on avolunteer basis.

In technical terms, current blockchain functionality is not scalable interms of maintaining security and decentralization, includingmaintaining the associated bandwidth and connectivity that thedecentralization provides.

Hence, there is a need for more robust and scalable solutions forimplementing blockchain transactions.

BRIEF DESCRIPTION OF THE DRAWINGS

A further understanding of the nature and advantages of particularembodiments may be realized by reference to the remaining portions ofthe specification and the drawings, in which like reference numerals areused to refer to similar components. In some instances, a sub-label isassociated with a reference numeral to denote one of multiple similarcomponents. When reference is made to a reference numeral withoutspecification to an existing sub-label, it is intended to refer to allsuch multiple similar components.

FIG. 1 is a schematic diagram illustrating a blockchain system that maybe secured using proof of transactions, in accordance with variousembodiments.

FIGS. 2A and 2B are graphical diagrams illustrating cost versus timecurves depicting required burn fees compared with total collected feesduring regular operation and during a reorganization attack, as part ofa blockchain system that may be secured using proof of transactions, inaccordance with various embodiments.

FIG. 2C is a graphical diagram illustrating a curve showing thedestruction of the money supply over time in a blockchain that has aburn fee but no mechanism for re-injecting the burned tokens back intothe network.

FIG. 3A is a schematic diagram illustrating an example of a conventionalblock including a plurality of transactions and a coinbase.

FIG. 3B is a schematic diagram illustrating an example of a blockincluding a plurality of transactions and a golden ticket, the blockbeing part of a blockchain system, in accordance with variousembodiments.

FIG. 4 is a schematic diagram illustrating a portion of a blockchainincluding a plurality of blocks, each block including a plurality oftransactions and a golden ticket, the blockchain being part of ablockchain system, in accordance with various embodiments.

FIG. 5 is a block diagram illustrating distribution of burn fees andcoinbase payout as part of a method for securing a blockchain withproof-of-transactions, in accordance with various embodiments.

FIG. 6 is a block diagram illustrating paysplit voting and difficultyvoting as part of another method for securing a blockchain withproof-of-transactions, in accordance with various embodiments.

FIGS. 7A-7C are flow diagrams illustrating a method for securing ablockchain with proof-of-transactions, in accordance with variousembodiments.

FIGS. 8A and 8B are flow diagrams illustrating another method forsecuring a blockchain with proof-of-transactions, in accordance withvarious embodiments.

FIG. 9 is a block diagram illustrating an exemplary computer or systemhardware architecture, in accordance with various embodiments.

FIG. 10 is a block diagram illustrating a networked system of computers,computing systems, or system hardware architecture, which can be used inaccordance with various embodiments.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

Overview

Various embodiments provide tools and techniques for implementingblockchain transactions, and, more particularly, to methods, systems,and apparatuses for securing a blockchain with proof-of-transactions.

The various embodiments provide a method to secure a cryptocurrency thatavoids a “free-rider” economic problem that affects manycryptocurrencies and hurts their ability to scale. The embodimentsdescribed herein solve this problem by utilizing a new security method(namely, “proof-of-transactions”) based on a multi-player voting systemthat is not susceptible to this free-rider problem and allows acryptocurrency network to divide its revenue between the set of nodes inthe peer-to-peer network that provides bandwidth and connectivity and aseparate set of nodes, the role of which is to safeguard the security ofthe system. By enabling a cryptocurrency network to reward nodes thatcontribute bandwidth and connectivity to the network in addition tothose that ensure the security of block issuance, the variousembodiments allow cryptocurrencies to increase the amount of dataprocessed by the network in an economically-efficient manner. Thispermits the development of fundamentally new applications, including,but not limited to, secure but decentralized email services,peer-to-peer social networks, pay-to-play websites, secure data-routingnetworks, SSH-key registries that are safe from man-in-the-middle(“MITM”) attacks, and/or the like.

Given the importance of blockchain technology and the need for moreeffective ways to scale up these networks to handle massive amounts ofdata, the importance of the various embodiments lies in the way theyoffer a simple and elegant solution to the free-rider problem, byoutlining an unintuitive method for securing a blockchain (i.e., aproof-of-transactions approach) that enables network fees to be used tocompensate both the nodes that provide security in the system as well asthe nodes that form the backbone of the peer-to-peer network. While thevoting method described here can be generalized to divide paymentsbetween any number of classes of actors in a blockchain network, simplyby extending the voting process so that all actors are required to voteto approve changes to network consensus, in the description below wefocus on a system with only two types of nodes (namely, “nodes” and“miners”) as these best describe the current needs of blockchainsystems. And our method has many unexpected virtues: allocating feesbetween these classes of nodes in a transparent way that responds inreal-time to the market-driven demands of the applications on thenetwork for more bandwidth or security respectively.

The following detailed description illustrates a few exemplaryembodiments in further detail to enable one of skill in the art topractice such embodiments. The described examples are provided forillustrative purposes and are not intended to limit the scope of theinvention.

In the following description, for the purposes of explanation, numerousspecific details are set forth to provide a thorough understanding ofthe described embodiments. It will be apparent to one skilled in theart, however, that other embodiments of the present invention may bepracticed without some of these specific details. In other instances,certain structures and devices are shown in block diagram form. Severalembodiments are described herein, and while various features areascribed to different embodiments, it should be appreciated that thefeatures described with respect to one embodiment may be incorporatedwith other embodiments as well. By the same token, however, no singlefeature or features of any described embodiment should be consideredessential to every embodiment of the invention, as other embodiments ofthe invention may omit such features.

Unless otherwise indicated, all numbers used herein to expressquantities, dimensions, and so forth used should be understood as beingmodified in all instances by the term “about.” In this application, theuse of the singular includes the plural unless specifically statedotherwise, and use of the terms “and” and “or” means “and/or” unlessotherwise indicated. Moreover, the use of the term “including,” as wellas other forms, such as “includes” and “included,” should be considerednon-exclusive. Also, terms such as “element” or “component” encompassboth elements and components comprising one unit and elements andcomponents that comprise more than one unit, unless specifically statedotherwise.

Various embodiments described herein, while embodying (in some cases)software products, computer-performed methods, and/or computer systems,represent tangible, concrete improvements to existing technologicalareas, including, without limitation, blockchain technology, and/or thelike. In other aspects, certain embodiments, can improve the functioningof user equipment or systems themselves (e.g., blockchain network nodes,blockchain network infrastructure, etc.), for example, by utilizing aproof-of-transactions approach to address the “free-rider” issue thatmay exist in conventional blockchain systems, and/or the like.

In particular, to the extent any abstract concepts are present in thevarious embodiments, those concepts can be implemented as describedherein by devices, software, systems, and methods that involve specificnovel functionality (e.g., steps or operations), such as, embedding, bya first node among a plurality of nodes in a peer-to-peer blockchainnetwork and into an unconfirmed transaction being propagated across saidnetwork for eventual inclusion in a block, a cryptographic signature anda network address that combines with other cryptographic signatures andnetwork addresses that have been previously embedded in the unconfirmedtransaction by one or more other nodes of the plurality of nodes in theblockchain network to create a chain of signatures that constitutes anindependently-verifiable and unforgeable record of a routing path thatthe unconfirmed transaction takes as it propagates across thepeer-to-peer blockchain network; validating, with a second node amongthe plurality of nodes, the chain of signatures embedded in thetransactions included in a block of a blockchain to confirm that theblock itself is valid in accordance with a set of consensus rules of theblockchain; quantifying, by one or more third nodes among the pluralityof nodes in the blockchain network and in accordance with a set ofconsensus rules of a blockchain, a level of difficulty associated withproducing a valid candidate block by reducing it to a burn fee, whereinthe burn fee is a cost denominated in a value of a token managed by theblockchain network; quantifying, by the one or more third nodes and inaccordance with the set of consensus rules of the blockchain, the valueof one or more transactions being included in a candidate block byreducing it to a burn value, wherein the burn value is a figuredenominated in a value of a token managed by the blockchain network;determining, with the one or more third nodes and in accordance with theset of consensus rules of the blockchain, whether a sum of individualburn values of the one or more transactions that are included in thecandidate block is equal to or greater than the burn fee of thecandidate block; based on a determination that the sum of individualburn values of the one or more transactions that are included in thecandidate block is equal to or greater than the burn fee of thecandidate block, determining, with the one or more third nodes, that thecandidate block is valid according to the set of consensus rules of theblockchain; generating, by a fourth node among the plurality of nodes inthe blockchain network, a golden ticket that contains a computationalpuzzle; generating, by a fifth node among the plurality of nodes in theblockchain network, a solution to the computational puzzle in the goldenticket, wherein the solution to the computational puzzle is used toselect, in a manner that cannot be anticipated by the fourth nodegenerating the golden ticket, one or more network nodes among theplurality of nodes in the blockchain network; and distributingblockchain tokens to the one or more network nodes that are selectedusing the solution to the computational puzzle in the golden ticket,wherein tokens allocated through use of golden tickets are split betweenone or more network nodes that have provided solutions to golden tickets(“lucky miners”) and one or more nodes selected by one or more solutionsto the golden tickets (“lucky nodes”), wherein distribution of thetokens split between lucky miners and lucky nodes is determined by apaysplit variable managed according to consensus rules of theblockchain, wherein a difficulty level of the computational puzzle isdetermined using a difficulty variable managed according to consensusrules of the blockchain, and/or the like, to name a few examples, thatextend beyond mere conventional computer processing operations. Thesefunctionalities can produce tangible results outside of the implementingcomputer system, including, merely by way of example, optimizedfunctionality of blockchain networks regardless of the number oftransactions or blocks in any particular blockchain, and over decades ofoperation, and/or the like, at least some of which may be observed ormeasured by users and/or service providers (including miners, nodes,and/or the like).

In an aspect, a method might comprise embedding, by a first node among aplurality of nodes in a peer-to-peer blockchain network and into anunconfirmed transaction being propagated across said network foreventual inclusion in a block, a cryptographic signature and a networkaddress that combines with other cryptographic signatures and networkaddresses that have been previously embedded in the unconfirmedtransaction by one or more other nodes of the plurality of nodes in theblockchain network to create a chain of signatures that constitutes anindependently-verifiable and unforgeable record of a routing path thatthe unconfirmed transaction takes as it propagates across thepeer-to-peer blockchain network. The method might further comprisevalidating, with a second node among the plurality of nodes, the chainof signatures embedded in the transactions included in a block of ablockchain to confirm that the block itself is valid in accordance witha set of consensus rules of the blockchain.

In some embodiments, each node among the plurality of nodes in thepeer-to-peer blockchain network might be associated with a uniquepublic/private key pair and a network address. In some cases, the uniquepublic/private key pair might comprise a public key and a private key.In some instances, the network address of a node among the plurality ofnodes might contain information derived from the unique public/privatekey pair of the node, and a cryptographic signature of the node might begenerated by using the private key of the unique public/private key pairof the node to sign a network address of a subsequent node among theplurality of nodes to which the transaction is routed by the node.

According to some embodiments, the network address and the other networkaddresses might constitute a plurality of network addresses. In somecases, a network address associated with an originating node thatoriginates the transaction might not be included in (or might beexcluded from) the plurality of network addresses, based on adetermination that information required to validate a cryptographicsignature associated with the originating node is already included inthe transaction. In some instances, the first node and the second nodemight be the same node. Alternatively, the first node and the secondnode might be different nodes.

In some embodiments, the method might further comprise quantifying, byone or more third nodes among the plurality of nodes in the blockchainnetwork and in accordance with a set of consensus rules of a blockchain,a level of difficulty associated with producing a valid candidate blockby reducing it to a burn fee, wherein the burn fee is a cost denominatedin a value of a token managed by the blockchain network; quantifying, bythe one or more third nodes and in accordance with the set of consensusrules of the blockchain, the value of one or more transactions beingincluded in a candidate block by reducing it to a burn value, whereinthe burn value is a figure denominated in a value of a token managed bythe blockchain network; determining, with the one or more third nodesand in accordance with the set of consensus rules of the blockchain,whether a sum of individual burn values of the one or more transactionsthat are included in the candidate block is equal to or greater than theburn fee of the candidate block; and based on a determination that thesum of individual burn values of the one or more transactions that areincluded in the candidate block is equal to or greater than the burn feeof the candidate block, determining, with the one or more third nodes,that the candidate block is valid according to the set of consensusrules of the blockchain.

According to some embodiments, the burn fee might be algorithmically setby at least one computing system in the blockchain network.Alternatively, or additionally, a burn fee needed for production of ablock might decrease over time in proportion to time elapsed sincegeneration of a preceding block in the blockchain. In some cases, a burnvalue of a transaction might comprise a transaction fee paid by anoriginator of the transaction for inclusion of its transaction in theblockchain. In some instances, a burn value of a transaction might beadjusted depending on whether the transaction contains a valid chain ofembedded cryptographic signatures establishing a route that thetransaction has taken in its course of propagating across the blockchainnetwork. In some cases, a burn value of a transaction might be adjusteddownward depending on the number of hops that the transaction has madeacross the blockchain network, as measured by an embedded chain ofcryptographic signatures contained within the transaction that documentits course of transmission across the blockchain network. In someinstances, the burn value of the transaction might be halved with eachadditional hop beyond a first hop that the transaction has made throughthe blockchain network from its point of origin to its point ofinclusion in a block.

In some embodiments, the method might further comprise determining, withat least a majority of the plurality of nodes in the blockchain network,whether aggregate burn values of the transactions included in a blockare sufficient to pay for the burn fee required for production of ablock; and based on a determination that the aggregate burn values ofthe transactions included in the block are sufficient to pay for theburn fee required for the production of the block, determining, with theat least a majority of the plurality of nodes in the blockchain network,that the block is valid and including, with the at least a majority ofthe plurality of nodes in the blockchain network, the block in ablockchain. In some instances, at least a portion of a difference invalue between a burn value of a transaction included in a block and aburn fee needed to produce a block, as measured in the value of thetoken managed by the blockchain network, might be granted to a nodeamong the plurality of nodes that produces the block as a form ofpayment for producing the block. In some cases, at least a portion ofthe burn value of the one or more transactions included in the candidateblock might be removed from circulation and not transferred to a nodethat produced the candidate block.

According to some embodiments, the method might further comprisepruning, by one or more fourth nodes among the plurality of nodes withinthe blockchain network, transaction slips in blocks in a blockchainpreceding an arbitrary block identified according to consensus rules ofthe blockchain; calculating, by the one or more fourth nodes among theplurality of nodes within the blockchain network, a value of all unspenttokens contained in all unpruned blocks preceding and including the lastblock being pruned; and adjusting a monetary policy of the blockchainnetwork so that the blockchain network will reintroduce the unspenttokens as tokens allocated in future blocks. In some cases, the unspenttokens might be reintroduced back into the blockchain network in a laterblock through use of golden tickets.

In another aspect, a system might comprise a first node among aplurality of nodes in a peer-to-peer blockchain network and a secondnode among the plurality of nodes. The first node might comprise atleast one first processor and a first non-transitory computer readablemedium communicatively coupled to the at least one first processor. Thefirst non-transitory computer readable medium might have stored thereoncomputer software comprising a first set of instructions that, whenexecuted by the at least one first processor, causes the first node to:embed, into an unconfirmed transaction being propagated across saidnetwork for eventual inclusion in a block, a cryptographic signature anda network address that combines with other cryptographic signatures andnetwork addresses that have been previously embedded in the unconfirmedtransaction by one or more other nodes of the plurality of nodes in theblockchain network to create a chain of signatures that constitutes anindependently-verifiable and unforgeable record of a routing path thatthe unconfirmed transaction takes as it propagates across thepeer-to-peer blockchain network.

The second node might comprise at least one second processor and asecond non-transitory computer readable medium communicatively coupledto the at least one second processor. The second non-transitory computerreadable medium might have stored thereon computer software comprising asecond set of instructions that, when executed by the at least onesecond processor, causes the second node to: validate the chain ofsignatures embedded in the transactions included in a block of ablockchain to confirm that the block itself is valid in accordance witha set of consensus rules of the blockchain. In some instances, the firstnode and the second node might be the same node. Alternatively, thefirst node and the second node might be different nodes.

In yet another aspect, a method might comprise embedding, by a firstnode among a plurality of nodes in a peer-to-peer blockchain network andinto an unconfirmed transaction being propagated across said network foreventual inclusion in a block, a cryptographic signature and a networkaddress that combines with other cryptographic signatures and networkaddresses that have been previously embedded in the unconfirmedtransaction by one or more other nodes of the plurality of nodes in theblockchain network to create a chain of signatures that constitutes anindependently-verifiable and unforgeable record of a routing path thatthe unconfirmed transaction takes as it propagates across thepeer-to-peer blockchain network; validating, with a second node amongthe plurality of nodes, the chain of signatures embedded in thetransactions included in a block of a blockchain to confirm that theblock itself is valid in accordance with a set of consensus rules of theblockchain; quantifying, by one or more third nodes among the pluralityof nodes in the blockchain network and in accordance with a set ofconsensus rules of a blockchain, a level of difficulty associated withproducing a valid candidate block by reducing it to a burn fee, whereinthe burn fee is a cost denominated in a value of a token managed by theblockchain network; quantifying, by the one or more third nodes and inaccordance with the set of consensus rules of the blockchain, the valueof one or more transactions being included in a candidate block byreducing it to a burn value, wherein the burn value is a figuredenominated in a value of a token managed by the blockchain network;determining, with the one or more third nodes and in accordance with theset of consensus rules of the blockchain, whether a sum of individualburn values of the one or more transactions that are included in thecandidate block is equal to or greater than the burn fee of thecandidate block; based on a determination that the sum of individualburn values of the one or more transactions that are included in thecandidate block is equal to or greater than the burn fee of thecandidate block, determining, with the one or more third nodes, that thecandidate block is valid according to the set of consensus rules of theblockchain; generating, by a fourth node among the plurality of nodes inthe blockchain network, a golden ticket that contains a computationalpuzzle; generating, by a fifth node among the plurality of nodes in theblockchain network, a solution to the computational puzzle in the goldenticket, wherein the solution to the computational puzzle is used toselect, in a manner that cannot be anticipated by the fourth nodegenerating the golden ticket, one or more network nodes among theplurality of nodes in the blockchain network; broadcasting, by the fifthnode, the solution to the golden ticket throughout the blockchainnetwork, the solution being included in a subsequent block that isproduced and validated by the blockchain network; and distributingblockchain tokens to the one or more network nodes that are selectedusing the solution to the computational puzzle in the golden ticket,wherein tokens allocated through use of golden tickets are split betweenone or more network nodes that have provided solutions to golden tickets(“lucky miners”) and one or more nodes selected by one or more solutionsto the golden tickets (“lucky nodes”), wherein distribution of thetokens split between lucky miners and lucky nodes is determined by apaysplit variable managed according to consensus rules of theblockchain, wherein a difficulty level of the computational puzzle isdetermined using a difficulty variable managed according to consensusrules of the blockchain.

In an aspect, a method might comprise quantifying, by one or more firstnodes among a plurality of nodes in a blockchain network and inaccordance with a set of consensus rules of a blockchain, a level ofdifficulty associated with producing a valid candidate block by reducingit to a burn fee, wherein the burn fee is a cost denominated in a valueof a token managed by the blockchain network; quantifying, by the one ormore first nodes and in accordance with the set of consensus rules ofthe blockchain, the value of one or more transactions being included ina candidate block by reducing it to a burn value, wherein the burn valueis a figure denominated in a value of a token managed by the blockchainnetwork; determining, with the one or more first nodes and in accordancewith the set of consensus rules of the blockchain, whether a sum ofindividual burn values of the one or more transactions that are includedin the candidate block is equal to or greater than the burn fee of thecandidate block; and based on a determination that the sum of individualburn values of the one or more transactions that are included in thecandidate block is equal to or greater than the burn fee of thecandidate block, determining, with the one or more first nodes, that thecandidate block is valid according to the set of consensus rules of theblockchain.

According to some embodiments, the burn fee might be algorithmically setby at least one computing system in the blockchain network.Alternatively, or additionally, a burn fee needed for production of ablock might decrease over time in proportion to time elapsed sincegeneration of a preceding block in the blockchain. In some cases, a burnvalue of a transaction might comprise a transaction fee paid by anoriginator of the transaction for inclusion of its transaction in theblockchain. In some instances, a burn value of a transaction might beadjusted depending on whether the transaction contains a valid chain ofembedded cryptographic signatures establishing a route that thetransaction has taken in its course of propagating across the blockchainnetwork. In some cases, a burn value of a transaction might be adjusteddownward depending on the number of hops that the transaction has madeacross the blockchain network, as measured by an embedded chain ofcryptographic signatures contained within the transaction that documentits course of transmission across the blockchain network. In someinstances, the burn value of the transaction might be halved with eachadditional hop beyond a first hop that the transaction has made throughthe blockchain network from its point of origin to its point ofinclusion in a block.

In some embodiments, the method might further comprise determining, withat least a majority of the plurality of nodes in the blockchain network,whether aggregate burn values of the transactions included in a blockare sufficient to pay for the burn fee required for production of ablock; and based on a determination that the aggregate burn values ofthe transactions included in the block are sufficient to pay for theburn fee required for the production of the block, determining, with theat least a majority of the plurality of nodes in the blockchain network,that the block is valid and including, with the at least a majority ofthe plurality of nodes in the blockchain network, the block in ablockchain. In some instances, at least a portion of a difference invalue between a burn value of a transaction included in a block and aburn fee needed to produce a block, as measured in the value of thetoken managed by the blockchain network, might be granted to a nodeamong the plurality of nodes that produces the block as a form ofpayment for producing the block. In some cases, at least a portion ofthe burn value of the one or more transactions included in the candidateblock might be removed from circulation and not transferred to a nodethat produced the candidate block.

In another aspect, a node among a plurality of nodes in a blockchainnetwork might be provided, the node comprising: at least one processor;and a non-transitory computer readable medium communicatively coupled tothe at least one processor. The non-transitory computer readable mediummight have stored thereon computer software comprising a set ofinstructions that, when executed by the at least one processor, causesthe node to: quantify, in accordance with a set of consensus rules of ablockchain, a level of difficulty associated with producing a validcandidate block by reducing it to a burn fee, wherein the burn fee is acost denominated in a value of a token managed by the blockchainnetwork; quantify, in accordance with the set of consensus rules of theblockchain, the value of one or more transactions being included in acandidate block by reducing it to a burn value, wherein the burn valueis a figure denominated in a value of a token managed by the blockchainnetwork; determine, in accordance with the set of consensus rules of theblockchain, whether a sum of individual burn values of the one or moretransactions that are included in the candidate block is equal to orgreater than the burn fee of the candidate block; and based on adetermination that the sum of individual burn values of the one or moretransactions that are included in the candidate block is equal to orgreater than the burn fee of the candidate block, determine that thecandidate block is valid according to the set of consensus rules of theblockchain.

According to some embodiments, the burn fee might be algorithmically setby at least one computing system in the blockchain network.Alternatively, or additionally, a burn fee needed for production of ablock might decrease over time in proportion to time elapsed sincegeneration of a preceding block in the blockchain. In some cases, a burnvalue of a transaction might comprise a transaction fee paid by anoriginator of the transaction for inclusion of its transaction in theblockchain. In some instances, a burn value of a transaction might beadjusted depending on whether the transaction contains a valid chain ofembedded cryptographic signatures establishing a route that thetransaction has taken in its course of propagating across the blockchainnetwork. In some cases, a burn value of a transaction might be adjusteddownward depending on the number of hops that the transaction has madeacross the blockchain network, as measured by an embedded chain ofcryptographic signatures contained within the transaction that documentits course of transmission across the blockchain network. In someinstances, the burn value of the transaction might be halved with eachadditional hop beyond a first hop that the transaction has made throughthe blockchain network from its point of origin to its point ofinclusion in a block.

In some instances, at least a portion of a difference in value between aburn value of a transaction included in a block and a burn fee needed toproduce a block, as measured in the value of the token managed by theblockchain network, might be granted to a node among the plurality ofnodes that produces the block as a form of payment for producing theblock. In some cases, at least a portion of the burn value of the one ormore transactions included in the candidate block might be removed fromcirculation and not transferred to a node that produced the candidateblock.

In yet another aspect, a method might comprise pruning, by one or morefirst nodes among the plurality of nodes within the blockchain network,transaction slips in blocks in a blockchain preceding an arbitrary blockidentified according to consensus rules of the blockchain; calculating,by the one or more first nodes among the plurality of nodes within theblockchain network, a value of all unspent tokens contained in allunpruned blocks preceding and including the last block being pruned; andadjusting a monetary policy of the blockchain network so that theblockchain network will reintroduce the unspent tokens as tokensallocated in future blocks. In some cases, the unspent tokens might bereintroduced back into the blockchain network in a later block throughuse of golden tickets.

In still another aspect, a node among a plurality of nodes in ablockchain network might be provided, the node comprising: at least oneprocessor; and a non-transitory computer readable medium communicativelycoupled to the at least one processor. The non-transitory computerreadable medium might have stored thereon computer software comprising aset of instructions that, when executed by the at least one processor,causes the node to: prune transaction slips in blocks in a blockchainpreceding an arbitrary block identified according to consensus rules ofthe blockchain; calculate a value of all unspent tokens contained in allunpruned blocks preceding and including the last block being pruned; andadjust a monetary policy of the blockchain network so that theblockchain network will reintroduce the unspent tokens as tokensallocated in future blocks. According to some embodiments, the unspenttokens are reintroduced back into the blockchain network in a laterblock through use of golden tickets.

In an aspect, a method might comprise generating, by a first networknode among a plurality of network nodes in a blockchain network, agolden ticket that contains a computational puzzle; generating, by asecond network node among the plurality of network nodes in theblockchain network, a solution to the computational puzzle in the goldenticket, wherein the solution to the computational puzzle is used toselect, in a manner that cannot be anticipated by the first network nodegenerating the golden ticket, one or more network nodes among theplurality of network nodes in the blockchain network; and distributingblockchain tokens to the one or more network nodes that are selectedusing the solution to the computational puzzle in the golden ticket.

In some instances, the first node and the second node might be the samenode. Alternatively, the first node and the second node might bedifferent nodes. In some embodiments, the golden ticket might be atleast one of included in a block published for inclusion in a blockchainor automatically associated with the block. In some cases, the goldenticket might comprise a random number that is created using dataassociated with the block. In some instances, the random number mightcomprise a cryptographic hash of data content contained within theblock. In some cases, the solution to the golden ticket might beincluded in a block immediately following the block in which the goldenticket is included was published. In some instances, any validblockchain might contain one or more golden tickets, each of which maybe solved only once.

According to some embodiments, a block might contain only one solutionto any particular golden ticket. In some cases, a block might containonly one golden ticket. In some instances, a block might contain asolution to only one golden ticket. In some cases, a block might beconsidered to be invalid based on a determination that the blockcontains a golden ticket solution that is invalid. In some instances,the solution to the computational puzzle in the golden ticket mightcomprise a product of a computationally difficult challenge that isindependently verifiable by other nodes in the blockchain network. Insome cases, the solution to the computational puzzle in the goldenticket that is generated by the second network node might be generatedbased on a hash of data associated with the golden ticket that meetsvalidity criteria as defined in consensus rules of the blockchain.

In some embodiments, the solution to the computational puzzle in thegolden ticket might be used to select one or more network nodes from asubset of network nodes among the plurality of network nodes in theblockchain network that are identified as being valuable routing nodeswith regard to production of a block containing the golden ticket. Insome instances, routing nodes might be determined to be valuable basedat least in part on data from a list of active routing nodes recordedwithin chains of cryptographic signatures and addresses embedded withintransactions that are contained in the block containing the goldenticket. In some cases, the list of active routing nodes might berestricted to network nodes that are recorded within chains ofcryptographic signatures and addresses embedded within transactions thatare included within the same block that contains a golden ticket. Insome instances, a likelihood that the one or more network nodes areselected might be weighted according to a determination that the one ormore network nodes are each perceived to contribute to health of theblockchain network as a whole, as measured based on consensus rules ofthe blockchain and using factors including at least one of a value of atransaction fee associated with each transaction or a burn value of atransaction.

According to some embodiments, an amount of tokens allocated through useof golden tickets might be equivalent to transaction fees paid in ablock containing a golden ticket that contains a computational puzzle towhich a solution has been generated. In some cases, an amount of tokensallocated through use of golden tickets might be equivalent totransaction fees paid in a block containing a golden ticket thatcontains a computational puzzle to which a solution has been generated,minus any value tokens allocated to a network node that generates theblock containing the golden ticket, and adjusted to be plus or minusanother amount determined by consensus rules of the blockchain tomaintain a consistent money supply. In some instances, tokens allocatedthrough use of golden tickets might be split between one or more networknodes that have provided solutions to golden tickets (“lucky miners”)and one or more nodes selected by one or more solutions to the goldentickets (“lucky nodes”). In some cases, votes to adjust variablescontained in one of a block, the golden ticket, or the solution might beused to adjust a value of consensus variables once the solution to thegolden ticket is included in the block and tokens are allocated to thelucky node and lucky miner in the blockchain network. In some instances,distribution of the tokens split between lucky miners and lucky nodesmight be determined by a paysplit variable managed according toconsensus rules of the blockchain. In some cases, the paysplit variablemight be adjusted to direct one of a greater proportion or a lesserproportion of the blockchain tokens being distributed to the one or morenetwork nodes that are selected.

In some embodiments, the method might further comprise embedding, withinone of a block or a golden ticket, a variable that indicates whether toincrease, to hold constant, or to decrease a value of the paysplitvariable managed according to the consensus rules of the blockchain. Insome instances, blocks that contain a vote of the block indicating oneof to decrease or to increase a value of the paysplit variable mightinclude only transactions that are consistent with the vote of the blockindicating the one of to decrease or to increase the value of thepaysplit variable. In alternative embodiments, the method might furthercomprise embedding, within a transaction, a variable that indicateswhether to increase, to hold constant, or to decrease a value of thepaysplit variable managed according to the consensus rules of theblockchain.

According to some embodiments, a difficulty level of the computationalpuzzle might be determined using a difficulty variable managed accordingto consensus rules of the blockchain. In some cases, the difficultyvariable might be adjusted to make selection of which network nodes toprovide eligible solutions one of more difficult or less difficult,wherein a higher difficulty corresponds to a reduced set of nodes thatwill be considered eligible to generate solutions under the consensusrules of the blockchain. In some instances, the method might furthercomprise embedding, within a solution to a golden ticket, a variablethat indicates whether to increase, to hold constant, or to decrease avalue of the difficulty variable managed according to the consensusrules of the blockchain. In some cases, the computational puzzle mightestablish a two-player chain, wherein the two-player chain establishedby the computational puzzles might be extended into a chain with anarbitrary number of participants, to perform at least one of providingadditional randomness or splitting allocation of tokens into a finerdistribution settling to more participants in the blockchain network.

In some embodiments, the method might further comprise embedding, withinone of a block or a golden ticket, a variable that indicates whether todecrease, to hold constant, or to increase a value of a networkconsensus variable (“vote of the block” or “vote of the golden ticket”).In some cases, blocks that contain a vote of the block indicating one ofto decrease or to increase a value of the network consensus variablemight include only transactions that are consistent with the vote of theblock indicating the one of to decrease or to increase the value of thenetwork consensus variable. In alternative embodiments, the method mightfurther comprise embedding, within a solution to a golden ticket, avariable that indicates whether to decrease, to hold constant, or toincrease a value of a network consensus variable (“vote of the goldenticket”). Alternatively, or additionally, the method might furthercomprise embedding, within a transaction, a variable that indicateswhether to decrease, to hold constant, or to increase a value of anetwork consensus variable (“vote of the transaction”).

In another aspect, a system might comprise a first network node among aplurality of network nodes in a blockchain network, a second networknode among the plurality of network nodes, and a computing system. Thefirst network node might comprise at least one first processor and afirst non-transitory computer readable medium communicatively coupled tothe at least one first processor. The first non-transitory computerreadable medium might have stored thereon computer software comprising afirst set of instructions that, when executed by the at least one firstprocessor, causes the first network node to: generate a golden ticketthat contains a computational puzzle.

The second network node might comprise at least one second processor anda second non-transitory computer readable medium communicatively coupledto the at least one second processor. The second non-transitory computerreadable medium might have stored thereon computer software comprising asecond set of instructions that, when executed by the at least onesecond processor, causes the second network node to: generate a solutionto the computational puzzle in the golden ticket, wherein the solutionto the computational puzzle is used to select, in a manner that cannotbe anticipated by the first network node generating the golden ticket,one or more network nodes among the plurality of network nodes in theblockchain network.

The computing system might comprise at least one third processor and athird non-transitory computer readable medium communicatively coupled tothe at least one third processor. The third non-transitory computerreadable medium might have stored thereon computer software comprising athird set of instructions that, when executed by the at least one thirdprocessor, causes the third network node to: distribute blockchaintokens to the one or more network nodes that are selected using thesolution to the computational puzzle in the golden ticket.

Various modifications and additions can be made to the embodimentsdiscussed without departing from the scope of the invention. Forexample, while the embodiments described above refer to particularfeatures, the scope of this invention also includes embodiments havingdifferent combination of features and embodiments that do not includeall of the above described features.

Specific Exemplary Embodiments

We now turn to the embodiments as illustrated by the drawings. FIGS. 1-9illustrate some of the features of the method, system, and apparatus forimplementing blockchain transactions, and, more particularly, tomethods, systems, and apparatuses for securing a blockchain withproof-of-transactions, as referred to above. The methods, systems, andapparatuses illustrated by FIGS. 1-9 refer to examples of differentembodiments that include various components and steps, which can beconsidered alternatives or which can be used in conjunction with oneanother in the various embodiments. The description of the illustratedmethods, systems, and apparatuses shown in FIGS. 1-9 is provided forpurposes of illustration and should not be considered to limit the scopeof the different embodiments.

With reference to the figures, FIG. 1 is a schematic diagramillustrating a blockchain system 100 that may be secured using proof oftransactions, in accordance with various embodiments.

In the non-limiting embodiment of FIG. 1, system 100 might comprise acomputing system 105, which might include, without limitation, one of aprocessor on a user device, a network node, a high speed signing networkcard(s), a network interface device, a server computer, a cloud-basedcomputing system, a distributed computing system, and/or the like.System 100 might further comprise a plurality of nodes 110 and aplurality of peer data storage systems 115 ₁-115 _(X) and 115 _(Y)-115_(N) (collectively, “peer data storage systems 115,” “data storage 115,”or the like), both distributed across a plurality of networks 120 a-120n (collectively, “networks 120” or the like). As shown in FIG. 1, forexample, distributed peer data storage systems #1 115 ₁ through #X 115_(X) might be disposed in one or more networks 120 a, while distributedpeer data storage systems #Y 115 _(Y) through #N 115 _(N) might bedisposed in one or more networks 120 n. Although not shown, distributedpeer data storage systems #X+1 115 _(X+1) through #Y−1 115 _(Y−1) (aswell as other nodes 110) might be disposed in one or more networks 120 bthrough 120 n-1. In some cases, each distributed peer storage system 115might comprise a database, and in some cases, a local server or localcomputing system that accesses the database in response to requests fromexternal or remote computing systems (e.g., computing system 105, nodes110, user devices, or the like). In some embodiments, computing system105 might communicatively couple with one or more of the distributedpeer data storage systems 115 in networks 120 via one or more networks125. In some cases, at least some of the plurality of nodes 110 mightalso be disposed in the one or more networks 125. System 100 mightfurther comprise one or more user devices 130 a-130 n and 135 a-135 n(collectively, “user devices,” “user devices 130,” or “user devices135,” or the like) disposed in one or more local area networks (“LANs”)140 a-140 n (collectively, “LANs 140” or the like). The user devicesmight be associated with users who might initiate or participate intransactions 145, which when validated or confirmed might beincorporated in one or more blocks in a blockchain. In some embodiments(as described below), a user associated with one of the user devicesmight participate in a three-party activity with a miner (which solvescomputational puzzles in the golden ticket) and a node (which providesbandwidth and connectivity for the transactions), by being provided withthe capability to tag their transactions with an optional paysplit vote(which the system 100 or the network might require might only beincluded if the votes are aligned in the same direction rather thanconflicting).

According to some embodiments, networks 120 a-120 n and 125 might eachinclude, without limitation, one of a local area network (“LAN”),including, without limitation, a fiber network, an Ethernet network, aToken-Ring™ network, and/or the like; a wide-area network (“WAN”); awireless wide area network (“WWAN”); a virtual network, such as avirtual private network (“VPN”); the Internet; an intranet; an extranet;a public switched telephone network (“PSTN”); an infra-red network; awireless network, including, without limitation, a network operatingunder any of the IEEE 802.11 suite of protocols, the Bluetooth™ protocolknown in the art, and/or any other wireless protocol; and/or anycombination of these and/or other networks. In a particular embodiment,the network might include an access network of the service provider(e.g., an Internet service provider (“ISP”)). In another embodiment, thenetwork might include a core network of the service provider and/or theInternet.

In operation, the plurality of nodes 110 might propagate an unconfirmedtransaction 145 (among a plurality of transactions 145) across at leastone of the one or more networks 120 a-120 n and/or the network(s) 125(collectively, “peer-to-peer blockchain network,” “blockchain network,”or “network,” or the like). The computing system 105 or a first node 110among the plurality of nodes 110 might embed, into the unconfirmedtransaction 145, a cryptographic signature and a network address thatcombines with other cryptographic signatures and network addresses thathave been previously embedded in the unconfirmed transaction by one ormore other nodes of the plurality of nodes 110 in the blockchain networkto create a chain of signatures that constitutes anindependently-verifiable and unforgeable record of a routing path thatthe unconfirmed transaction 145 takes as it propagates across thepeer-to-peer blockchain network. The computing system 105 or a secondnode 110 among the plurality of nodes 110 might validate the chain ofsignatures embedded in the transactions included in a block of ablockchain to confirm that the block itself is valid in accordance witha set of consensus rules of the blockchain.

In some embodiments, each node among the plurality of nodes 110 in thepeer-to-peer blockchain network might be associated with a uniquepublic/private key pair and a network address. In some cases, the uniquepublic/private key pair might comprise a public key and a private key.In some instances, the network address of a node among the plurality ofnodes 110 might contain information derived from the uniquepublic/private key pair of the node (in some cases, the information isderived from the private key of the unique public/private key pair ofthe node, while in other cases (e.g., in some PKI systems with which thepublic key cannot necessarily be derived from the private, or the like),the information need not be derived from the private key itself), and acryptographic signature of the node might be generated by using theprivate key of the unique public/private key pair of the node to sign anetwork address of a subsequent node among the plurality of nodes 110 towhich the transaction is routed by the node.

According to some embodiments, the network address and the other networkaddresses might constitute a plurality of network addresses. In somecases, a network address associated with an originating node thatoriginates the transaction might not be included in (or might beexcluded from) the plurality of network addresses, based on adetermination that information required to validate a cryptographicsignature associated with the originating node is already included inthe transaction. In alternative cases, a network address associated withthe originating node might be included regardless of whether informationrequired to validate a cryptographic signature associated with theoriginating node has already been included in the transaction. In someinstances, the first node and the second node might be the same node.Alternatively, the first node and the second node might be differentnodes.

In some embodiments, the computing system 105 or one or more third nodesamong the plurality of nodes 110 might quantify a level of difficultyassociated with producing a valid candidate block by reducing it to aburn fee, in accordance with a set of consensus rules of a blockchain.In some cases, the burn fee might be a cost denominated in a value of atoken managed by the blockchain network. According to some embodiments,the computing system 105 or the one or more third nodes might quantifythe value of one or more transactions being included in a candidateblock by reducing it to a burn value, in accordance with the set ofconsensus rules of the blockchain. In some instances, the burn valuemight be a figure denominated in a value of a token managed by theblockchain network. In some embodiments, the computing system 105 or theone or more third nodes might determine whether a sum of individual burnvalues of the one or more transactions that are included in thecandidate block is equal to or greater than the burn fee of thecandidate block, in accordance with the set of consensus rules of theblockchain. Based on a determination that the sum of individual burnvalues of the one or more transactions that are included in thecandidate block is equal to or greater than the burn fee of thecandidate block, the computing system 105 or the one or more third nodesmight determine that the candidate block is valid according to the setof consensus rules of the blockchain.

According to some embodiments, the burn fee might be algorithmically setby at least one computing system 105 or at least one node among theplurality of nodes 110 in the blockchain network. Alternatively, oradditionally, a burn fee needed for production of a block might decreaseover time in proportion to time elapsed since generation of a precedingblock in the blockchain (as depicted in FIGS. 2A and 2B, which arefurther described below). In some cases, a burn value of a transactionmight comprise a transaction fee paid by an originator of thetransaction for inclusion of its transaction in the blockchain. In someinstances, a burn value of a transaction might be adjusted depending onwhether the transaction contains a valid chain of embedded cryptographicsignatures establishing a route that the transaction has taken in itscourse of propagating across the blockchain network. In some cases, aburn value of a transaction might be adjusted downward depending on thenumber of hops that the transaction has made across the blockchainnetwork, as measured by an embedded chain of cryptographic signaturescontained within the transaction that document its course oftransmission across the blockchain network. In some instances, the burnvalue of the transaction might be halved with each additional hop beyonda first hop that the transaction has made through the blockchain networkfrom its point of origin to its point of inclusion in a block.

In some embodiments, at least a majority of the plurality of nodes 110in the blockchain network might determine whether aggregate burn valuesof the transactions included in a block are sufficient to pay for theburn fee required for production of a block. Based on a determinationthat the aggregate burn values of the transactions included in the blockare sufficient to pay for the burn fee required for the production ofthe block, the at least a majority of the plurality of nodes 110 in theblockchain network might determine that the block is valid and mightinclude the block in a blockchain. In some instances, at least a portionof a difference in value between a burn value of a transaction includedin a block and a burn fee needed to produce a block, as measured in thevalue of the token managed by the blockchain network, might be grantedto a node among the plurality of nodes 110 that produces the block as aform of payment for producing the block. In some cases, at least aportion of the burn value of the one or more transactions included inthe candidate block might be removed from circulation and nottransferred to a node that produced the candidate block.

According to some embodiments, the computing system 105 or one or morefourth nodes among the plurality of nodes 110 within the blockchainnetwork might prune all transaction slips in blocks in a blockchainpreceding an arbitrary block identified according to consensus rules ofthe blockchain, and might calculate a value of all unspent tokenscontained in all unpruned blocks preceding and including the last blockbeing pruned. The computing system 105 or at least one node among theplurality of nodes 110 might adjust a monetary policy of the blockchainnetwork so that the blockchain network would reintroduce (or recycle)the unspent tokens as tokens allocated in future blocks. In some cases,the unspent tokens might be reintroduced back into the blockchainnetwork in a later block through use of golden tickets.

In some embodiments, the computing system 105 or a fifth node among theplurality of nodes 110 in the blockchain network might generate a goldenticket that contains a computational puzzle. The computing system 105 ora sixth node among the plurality of nodes 110 in the blockchain networkmight generate a solution to the computational puzzle in the goldenticket, where the solution to the computational puzzle might be used toselect one or more network nodes among the plurality of nodes 110 in theblockchain network, in a manner that cannot be anticipated by thecomputing system 105 or the fifth node generating the golden ticket. Insome instances, at least two of the first node, the second node, thethird node, the fourth node, the fifth node, the sixth node, one of theselected one or more network nodes, and/or the computing system 105might be the same node. Alternatively, the first node, the second node,the third node, the fourth node, the fifth node, the sixth node, the oneof the selected one or more network nodes, and the computing system 105might be different nodes. In some embodiments, the golden ticket mightbe at least one of included in a block published for inclusion in ablockchain or automatically associated with the block, and/or the like.In some cases, the golden ticket might include, without limitation, arandom number that is created using data associated with the block. Insome instances, the random number might comprise a cryptographic hash ofdata content contained within the block. In some cases, the solution tothe golden ticket might be included in a block immediately following theblock in which the golden ticket is included was published. In someinstances, any valid blockchain might contain one or more goldentickets, each of which may be solved only once.

According to some embodiments, a block might contain only one solutionto any particular golden ticket. In some cases, a block might containonly one golden ticket. In some instances, a block might contain asolution to only one golden ticket. In some cases, a block might beconsidered to be invalid based on a determination that the blockcontains a golden ticket solution that is invalid. In some instances,the solution to the computational puzzle in the golden ticket mightcomprise a product of a computationally difficult challenge that isindependently verifiable by other nodes 110 in the blockchain network.In some cases, the solution to the computational puzzle in the goldenticket that is generated by the sixth node might be generated based on ahash of data associated with the golden ticket that meets validitycriteria as defined in consensus rules of the blockchain.

In some embodiments, the solution to the computational puzzle in thegolden ticket might be used to select one or more network nodes from asubset of network nodes among the plurality of network nodes 110 in theblockchain network that are identified as being valuable routing nodeswith regard to production of a block containing the golden ticket. Insome instances, routing nodes might be determined to be valuable basedat least in part on data from a list of active routing nodes recordedwithin chains of cryptographic signatures and addresses embedded withintransactions that are contained in the block containing the goldenticket. In some cases, the list of active routing nodes might berestricted to network nodes 110 that are recorded within chains ofcryptographic signatures and addresses embedded within transactions thatare included within the same block that contains a golden ticket. Insome instances, a likelihood that the one or more network nodes areselected might be weighted according to a determination that the one ormore network nodes are each perceived to contribute to health of theblockchain network as a whole, as measured based on consensus rules ofthe blockchain and using factors including at least one of a value of atransaction fee associated with each transaction or a burn value of atransaction.

In some instances, the computing system 105 or the sixth node among theplurality of nodes 110 in the blockchain network might broadcast thesolution to the golden ticket throughout the blockchain network, thesolution being included in a subsequent block that is produced andvalidated by the blockchain network. According to some embodiments, thecomputing system 105 or a node among the plurality of nodes 110 mightdistribute blockchain tokens to the one or more network nodes that areselected using the solution to the computational puzzle in the goldenticket. In some instances, an amount of tokens allocated through use ofgolden tickets might be equivalent to transaction fees paid in a blockcontaining a golden ticket that contains a computational puzzle to whicha solution has been generated. In some cases, an amount of tokensallocated through use of golden tickets might be equivalent totransaction fees paid in a block containing a golden ticket thatcontains a computational puzzle to which a solution has been generated,minus any value tokens allocated to a network node that generates theblock containing the golden ticket, and adjusted to be plus or minusanother amount determined by consensus rules of the blockchain tomaintain a consistent money supply. In some cases, tokens allocatedthrough use of golden tickets might be split between one or more networknodes that have provided solutions to golden tickets (“lucky miners”)and one or more nodes selected by one or more solutions to the goldentickets (“lucky nodes”). In some instances, distribution of the tokenssplit between lucky miners and lucky nodes might be determined by apaysplit variable managed according to consensus rules of theblockchain, while a difficulty level of the computational puzzle mightbe determined using a difficulty variable managed according to theconsensus rules of the blockchain.

In some cases, the difficulty variable might be adjusted to makeselection of which network nodes to provide eligible solutions eithermore difficult or less difficult, where a higher difficulty correspondsto a reduced set of nodes that will be considered eligible to generatesolutions under the consensus rules of the blockchain. In someinstances, the computing system 105 or at least one of the nodes 110might embed, within a solution to a golden ticket, a variable thatindicates whether to increase, to hold constant, or to decrease a valueof the difficulty variable managed according to the consensus rules ofthe blockchain. In some cases, the computational puzzle might establisha two-player chain, wherein the two-player chain established by thecomputational puzzles might be extended into a chain with an arbitrarynumber of participants, to perform at least one of providing additionalrandomness or splitting allocation of tokens into a finer distributionsettling to more participants in the blockchain network.

In some embodiments, the computing system 105 or at least one of thenodes 110 might embed, within one of a block or a golden ticket, avariable that indicates whether to decrease, to hold constant, or toincrease a value of a network consensus variable (“vote of the block” or“vote of the golden ticket”). In some cases, blocks that contain a voteof the block indicating whether to decrease or to increase a value ofthe network consensus variable might include only transactions that areconsistent with the vote of the block indicating whether to decrease orto increase the value of the network consensus variable. In alternativeembodiments, the computing system 105 or at least one of the nodes 110might embed, within a solution to a golden ticket, a variable thatindicates whether to decrease, to hold constant, or to increase a valueof a network consensus variable (“vote of the golden ticket”).Alternatively, or additionally, the computing system 105 or at least oneof the nodes 110 might embed, within a transaction, a variable thatindicates whether to decrease, to hold constant, or to increase a valueof a network consensus variable (“vote of the transaction”).

As in other blockchains, users in the blockchain network of the variousembodiments create transactions and broadcast them into a mesh grid thatassembles these transactions into blocks and arranges these blocks intoa sequential blockchain that represents the transaction history of thenetwork, treating the longest chain at any time as the ledger of record.Unlike other types of blockchains, the methods according to the variousembodiments change the class of nodes that have the right to bundletransactions into blocks.

As alluded to above, in traditional blockchains like Bitcoin andEthereum™, the work of creating blocks is given to “miners” or “stakers”who assume financial risk for the right to issue blocks: contributingcurrency or hashpower to the network in a way that exposes them to therisk of losing money if they are unlucky or if they cheat the system,but that results in the network becoming more secure against attackerswho wish to over-write payment or censor network activity. These nodesare not necessarily the same as the nodes that handle the majority ofthe traffic in the peer-to-peer system. In both networks, the nodes thatfocus on earning revenue generally “specialize.”

In contrast to this traditional approach, in our approach, it is theregular nodes in the peer-to-peer network (namely, the ones that providebandwidth and that collect and propagate transactions) that have theright to create blocks, incentivized to do so to secure the revenueassociated with bundling transactions into blocks. To regulate the paceof block production and secure the system, it is necessary that thisaction cannot be free, and thus we specify that producing a blockrequires the payment of a “burn fee” that is set algorithmically by thenetwork and denoted in the currency of the network token (the same tokenin which fees are paid). In the software developed to use this method,our algorithm sets this “burn fee” to a high value immediately after ablock is found and decreases it gradually over time until it eventuallyhits zero, at which point any node on the network can produce a blockfree-of-charge. While this design eliminates the possibility of a “hashcrash” by putting an upper-limit on the time between blocks, nodes arestill expected to produce blocks as soon as the transaction fees theyhave in their mempool are greater than the “burn fee” required by thenetwork (i.e., as soon as it is profitable). This economic dynamic isillustrated in FIG. 2A, as further described below.

It is easy to see how this results in an optimized block time: the paceof block production in our system is determined by the overall volume oftransactions fees paid into the system as a whole. And while it is lessobvious that this provides equivalent security to a proof-of-worksystem, consideration will show that it does: attackers who wish tore-write the main chain will not succeed unless they are capable ofproducing blocks at a faster pace than the network as a whole, somethingthat in practice requires either access to a greater flow of transactionfees than the rest of the network combined, or a willingness on the partof the attacker to burn their own capital to create fake transactionsthat pay real fees. Either way, as FIG. 2B (which is further describedbelow) illustrates, the cost of any attack on the network increasesrelative to the increase in speed that attackers need to achieve inblock production to overcome the main chain's lead and build thelongest-chain.

By creating a relationship between the speed of block production and thecost paid by nodes on the network, we create a lever we can use to makeattacking the network prohibitively expensive. Our security dynamic issimilar to that of other blockchains in the sense that attacking thenetwork now requires attackers to expend significant resources. And toensure that even minor increases in the pace of block production costsignificant amounts of money, we specify that our networkalgorithmically adjusts its “burn fee” upwards over time to keep blocktime constant as transaction volume grows. Although any method whichaccomplishes this is fine, we handle it in practice by adjusting ourburn fee up and down every N blocks so as to keep our desiredequilibrium block time constant.

While this method works, and distributes the fees from transactions tothe nodes that take part in the peer-to-peer propagation network, itcreates an economic problem that we need to solve to implement it inpractice. Specifically, our requirement that nodes pay a “burn fee” tocreate blocks necessarily results in a process of steady deflation (asdepicted in FIG. 2C, which is further described below) that graduallydestroys all of the currency in our system. To avoid these deflationarypressures, our system thus requires the provision of a separatemechanism to reintroduce our “burned” currency back into our system. Butwe cannot do this in any way that gives the block-issuing node anycontrol over how these funds are dispersed. The reason for this is thatif the same blocks that pay the “burn fees” can also influence thedistribution of those fees, they can game or sibyl the network to lowertheir cost of producing future blocks, and thus their cost of attackingthe network. Additionally, any ability for nodes to “subsidize” futureblock production with fees from a previous block turns the activity ofblock production into a thinly-disguised proof-of-work approach wherethe competitive advantage in block-issuance comes not from gatheringtransactions on the peer-to-peer network so much as devotingcomputational resources to gaming the system.

What this means in terms of blockchain design is that we must separatethe act of producing blocks from the act of distributing funds. This issomething new since in existing systems the fees and coinbase gatheredby “miners” and “stakers” are issued to the nodes that produce theactual blocks. And our method for solving this problem is genuinelynovel, working through the creation of a system that plays out betweenour two main classes of nodes (those that contribute to the peer-to-peernetwork and those that serve the security function of the system). Andour method works by pitting these two classes of nodes against eachother in a long-term struggle to control the distribution of revenueproduced by the system. This struggle is systematized through amulti-player voting system that approves of changes to consensusnetwork-wide settings like the percentage of the fee that goes to nodesin the peer-to-peer network versus the percentage of the fee that goesto the miners.

In practice, our own system works as follows. Every time a node producesa block, it collects what profit it can (the transaction fees it isallowed to use minus the required network burn fee) and bundles theremaining transaction fees it has collected into a “golden ticket” thatcontains a computational puzzle for the miners in the network to solve.In addition to producing this “golden ticket,” the node that producesthe block in our peer-to-peer network also includes a vote on whether toincrease, decrease, or hold constant the share of the “burn fee” thatwill be distributed to “miners” as opposed to being distributed to the“nodes,” where “miners” herein refers to nodes that choose to solvecomputational puzzles and “nodes” refers to nodes that provide bandwidthand connectivity in the peer-to-peer network. This vote over thedistribution of income is referred to herein as the “paysplit vote.” Theconsensus network determination of how fees are distributed is referredto herein as the “paysplit.”

As nodes produce blocks and propagate them, miners examine the “goldentickets” (along with their paysplit votes) and choose for themselveswhich blocks they wish to support. If they decide they want to support agolden ticket, they must find a solution to a computationally difficultpuzzle and share it with the rest of the network.

Although there are many possible variants for this puzzle, thecomputational puzzle that is selected for miners to solve, according tosome non-limiting embodiments, includes, but is not limited to, thechallenge of producing a public/private keypair that can sign ahash-value in a way that the resulting signature meets criteria that canbe easily tested by the rest of the network. Miners, in some instances,are suggested to start with an SHA256 hash or the like of the contentsof the golden ticket, with their challenge being appending to this hashtheir own public key and then signing the hash+key combination such thatit produces a cryptographic signature (i.e., signing the results withtheir private key) where the final N digits in both the signature andthe golden ticket hash value match, where N here is a consensus variablethat is adjusted up or down by the network through a separate“difficulty vote” in a process that will be described shortly. Thereason for using this method is that miners can publish the proof thatthey have found a solution into the network without providing theability for other nodes or miners to steal it (since only the miner thatfound the proof has the necessary private key to create a validsignature, and since the public key is associated with the miner whofound the solution). And yet all nodes can easily verify that the minerhas indeed found a valid proof by simply checking the profferedsignature against their public key.

All that is really needed in this puzzle is that the miners have theability to solve a computationally-difficult task, the difficulty ofwhich can be adjusted, and of which proof of success can be broadcastwithout sharing the ability for other players to copy the solution andthus steal the funds. Regardless of the specific puzzle chosen, wespecify that should a miner choose to devote the computational effortrequired to solve one of these golden tickets, and should it succeed inactually finding a workable solution, the miner must propagate itssolution back into the network as a regular fee-paying transaction intime for inclusion in the very next block (variations with longer timelimits are permissible as well). Miner solutions to the golden ticketmust include all of the information needed by third-parties to verifythat the miner has solved the computational puzzle successfully, alongwith the previously mentioned second vote on whether to increase,decrease, or hold constant the difficulty of the computational puzzleitself (“difficulty vote”).

Once a golden ticket is solved by a miner and its solution is includedin the next block, the “burn fee” contained in the golden ticket isreleased to the network, split between the miner that found the solutionand (a randomly selected) one of the nodes that participates in thepeer-to-peer network and that propagates transactions according to theconsensus paysplit values. And while any method for selecting thisrandom node in the peer-to-peer network is acceptable as long as itrewards nodes that actually propagate and source transactions, in someembodiments of the current codebase, a hash-value produced in the minersolution may be used as a random input to an algorithm that selects anode that was involved in propagating one of the transactions found inthe previous block, and whose address or public key can be found in thepath-history of the transaction (as described further below). The logicof how and when fees are distributed is presented in FIG. 5, which isfurther described below.

Additionally, once a golden ticket has been solved and has beenincorporated into the blockchain, the two votes that have been made inthe process (“paysplit vote” and “difficulty vote”) are then used asinputs by the network into an algorithm that periodically adjusts theconsensus paysplit and difficulty settings for all subsequent blocks onthat chain. The logic of how votes are generated and counted ispresented in FIG. 6, which is further described below.

In practice, this dynamic creates a struggle between miners and nodesfor the revenue created by the system, driving the network into along-term equilibrium where revenue is distributed between the nodes inthe peer-to-peer network and the miners “securing” the network accordingto the underlying economic costs of bandwidth and security provision.The security of the network is increased as the network grows andtransaction volume grows regardless of the activity of the miners. Butthe miners nonetheless play an important role in preventing attacks, forthe higher they drive the difficulty of solving the “golden tickets,”the greater is the difficulty for any attacker to change the consensuspaysplit and difficulty settings of the network in a way that will allowthem to produce blocks at a faster pace than the main chain and thuslaunch a successful attack on it.

The dynamic described above is sufficient to secure the network. Tostrengthen it against more subtle attacks, a few other changes mayoptionally be implemented as well.

To encourage the levels of bandwidth and security provision provided byour multiple classes of nodes to reflect the needs of the users andapplications on the network (rather than those of the nodes and minersthemselves), we specify that users who send transactions into thenetwork may optionally tag their transactions with a separate paysplitvote. And we specify that should a user-originated transaction contain apaysplit vote to either increase or decrease the consensus paysplitsetting, it can only be included in a node-produced block that votes inthe same direction.

To make attacks on the network more expensive and make it easier toidentify which nodes are active in supporting the peer-to-peer network,we can also optionally have nodes sign transactions as they propagatethrough our network, creating an unforgeable history of the path eachtransaction that is included in the transaction and documents itstransmission from its point of origin to its point of confirmation andinclusion in a block. We can also optionally specify that nodes arepermitted to bundle any transaction in any block, but cannot use thefees paid by transactions against the “burn fee” they need to pay unlesstheir own node can be found in the cryptographically signed transactionpath for that specific transaction. Additionally, to make sibyl attackson the network economically unproductive, we decrease the amount of theoverall transaction fee that any node can allocate to its “burn fee”with each hop that a transaction takes through the network (with theremainder being simply added automatically to the golden ticket). And toprevent a subtle attack that involves hostile players manipulatingnetwork-wide changes in the burn fee to produce blocks at a faster pacethan the rest of the network, the rules may stipulate that nodes preferblocks that have a higher initial burn fee than blocks that have a lowerburn fee at any particular block depth (i.e., if two blocks share thesame block ID but one has a higher burn fee, the latter becomes thepreferred block).

The Saito Network:

The blockchain system or approach described herein (also referred toherein as the “Saito Network,” “Saito platform,” or the like) is acryptocurrency platform for applications that need to send large amountsof data across the blockchain. You can use it today to build“unastroturfable” Internet forums, decentralized social networks,pay-to-play websites, distributed data-routing services, peer-to-peeremail hosting, SSH-key registries that are secure from MITM attacks,and/or the like.

On a technical level, the Saito platform described herein is notable forits use of a disposable blockchain, a proof-of-transactions system thatsplits network fees between bandwidth and security providers, and aneconomic incentive structure that protects the network from sibylattacks and ensures that even attackers with overwhelming influence inany sector cannot dictate the behavior of the network as a whole.

The Disposable Blockchain:

As in other blockchains, users in the blockchain network describedherein (i.e., the Saito Network) create transactions and broadcast theminto a mesh grid that assembles them into sequential blocks, treatingthe longest chain as the ledger of record. While all transactionssupport basic payment functionality, they also include a signed“message” field where data can be bundled and read by applications thatsit atop the network.

In the case of other blockchains, developers have been reluctant topermit users to include extra data in transactions out of fear ofplacing ever-increasing bandwidth and storage requirements on nodes. Inthe case of Bitcoin, this has led to conflict not only over the maximumblock size, but even over the more trivial question of whethertransactions should support a 40 or 80-byte OP_RETURN field.

For the Saito Network, we take for granted that even an 80-byte messagefield is hardly enough space for real-world applications, and oursolution to the problem of data-creep is to use a disposable blockchain.In this system, the nodes in our network can simply throw out the oldestdata in our ledger at predictable intervals, making it impossible forpayment inputs to be used after an arbitrary length of time. Since the“genesis block” is always creeping forward there is no definitivestarting time for the network, yet we do not consider this a majorvulnerability because even Bitcoin users are vulnerable tochain-poisoning at their first point of contact (i.e., client softwaredownload). And there remain many ways for users to guard themselvesagainst the risk of ending up on a minority fork: primarily byconnecting to multiple trusted peers and monitoring the longest-chain.And cross-fork payment issues can also be avoided by the use oflarge-transaction “inception payments” (or payments-within-payments) inwhich the receiver only publishes the bundled payment to the blockchainonce they can confirm they have access to the funds contained therein(i.e., as soon as they confirm they are on the same chain as the paymentinput). Here as elsewhere, extensible transactions allow creative waysto solve many problems that occur in other blockchains. And there is nopractical limit to our creativity: we can even chain “inceptionpayments” to include any number of participants, with the only limitbeing the point where the fees required for transmitting the transactionmake the payment itself economically infeasible (i.e., the dreaded“limbo payment”).

Our disposable blockchain gives the Saito network many advantages overalternate systems. Unlike Bitcoin, we do not face an ever-expanding UTXOset because so-called “dust transactions” (i.e., transactions thatcontain minuscule and unspendable amounts of bitcoins or tokens and thatare encoded with human-readable, non-payment information into falseaddresses, or the like) are eliminated organically from our system overtime. Uncertainty over what the network-wide rates of inflation anddeflation are also avoided, since lost funds are recycled orreintroduced into future coinbase issuances and the exact amount ofcurrency in circulation at any point is calculated. The risk ofattackers launching long-term re-organization attacks is also lower withthe Saito Network than with competing networks because many long-termattacks become impossible to pull-off with a disposable blockchain:attackers need not only produce a viable competing blockchain aselsewhere, but now also need to do so before the network collectivelydiscards the block they are using as the basis for their proposed fork.

While a disposable blockchain helps solve the technical challengesinvolved in scaling up transaction sizes, there are two more fundamenteconomic problems we need to solve as well: the “tragedy of the commons”problem that is caused when transaction fees do not cover the true costof long-term data storage, and the “free rider” problem that exists whenminers (who provide transaction irreversibility) are paid out of feeswhile nodes (which provide bandwidth and open-access) are expected tooperate on a volunteer basis. Because the bandwidth requirements ofrunning a Saito node increase with transaction sizes, both problems willbe intractable in our network unless we find some way to pay for nodeprovision in addition to network security. This is a hard problembecause the amount of funding we need for each group of actors dependsentirely on economic pressures and not on technical ones. The problem isfurther complicated because the distribution of fees cannot be madearbitrarily as with Bitcoin but must instead be driven by a mechanismthat allows the actual economic demands of applications for securityvis-a-vis open access and connectivity to be reflected in thefee-distribution mechanism. On top of all of this, our solution mustalso be secure against attack, and drive all actors in the network topromote the welfare of the network even as it drives them to maximizetheir private profits.

The Solution:

As with Bitcoin, nodes in the Saito Network create blocks to secure thefees associated with bundling transactions. Unlike Bitcoin, the cost ofproducing a block is not the arbitrary expenditure of “hash power” butrather a “burn fee” that is set algorithmically by the network. In someembodiments, this “burn fee” is set to a high value immediately after ablock is found and decreases in stepwise fashion until it eventuallyhits zero, at which point any node on the network can produce a blockfree-of-charge. While this design eliminates the possibility of a “hashcrash” by putting an upper-limit on the time between blocks, nodes arestill expected to produce blocks faster on average: as soon as thetransaction fees they have in their mempool are greater than the “burnfee” required by the network (i.e., as soon as it is profitable). Thisis shown in FIG. 2A, as further described below.

It is easy to see how this results in an optimized block time: the paceof block production is determined by the volume of transactions feespaid into the system as a whole. And while it is less obvious that thisprovides equivalent security to a proof-of-work system, considerationwill show that it does: attackers who wish to re-write the main chainwill not succeed unless they are capable of producing blocks at a fasterpace. And this means in practice that they will need either a greaterflow of transaction fees than the rest of the network combined, or bewilling to burn their own capital to make up the difference: creatingfake transactions that nonetheless burn real fees. As FIG. 2Billustrates, the cost any attack thus depends on how quickly theattackers need to produce blocks to overcome the main chain.

To ensure that even minor and temporary increases in the pace of blockproduction cost significant amounts of money, the Saito Networkautomatically adjusts its “burn fee” upwards over time to keep blocktime constant as transaction volume grows. One subtle benefit of thisdesign is that attacking the network grows more expensive the moretransactions it serves, essentially creating a virtuous cycle thatencourages economic activity to concentrate on the most secure chain.Another more subtle advantage of this approach is that by quantifyingthe costs of any attack, users and applications can gauge for themselveswhether security is adequate or inadequate for their needs. Yet anothersubtle benefit of this design is that long-term attacks become far muchexpensive to pull-off than short-term chain re-organizations, since thepace of block production in long-term chain re-writes needs to besignificantly higher than in short-term ones in order for attackers topull off a network-wide chain re-organization before theirforking-off-block is discarded from the ledger.

Of course, there is also an issue we need to overcome, as depicted inFIG. 2C. As can be seen in FIG. 2C, any network that relies upon nodesto “burn capital” to issue blocks will eventually run out of funds. Wecan avoid this by adding a coinbase to our system, but as long as theblock-finding node has any influence over how funds are distributed (asis the case in other blockchains), a savvy attacker can sibyl orotherwise game the block-finding process to increase their chances ofcapturing the revenue. If we were to use the new block hash value torandomly distribute funds between nodes in the network, for instance, anattacker could experiment with producing multiple valid blocks until itfound one that benefited it individually. And this design thus fails ourrequirement that economic incentives need to promote the welfare of thesystem as whole, since any flaw of this nature not only reduces the costof a re-organization attack (encouraging attackers to subsidize theirattacks with recycled money), but also transforms our network into athinly-disguised proof-of-work system, one in which nodes now compete toearn profits not by processing transactions efficiently so much asexpending resources to sibyl/game the network.

Fortunately, we have a solution to this problem, and it constitutes oneof the major innovations of the Saito Network. And it is remarkablesince in addition to making it impossible for nodes to game currencyissuance, and thus enable proof-of-transactions as a secure alternativeto both proof-of-stake and proof-of-work, our method also secures thenetwork against sibyl attacks, ensures that nodes continually optimizethe distribution of transactions through the system, and creates asystem that naturally allocates fees between bandwidth and securityproviders in the most efficient way possible. This solution is theincorporation of a system in our fee-distribution process that ensuresgood behavior by the three players in the network: users, nodes, andminers. And then we ensure that the resulting dynamic always protectsthe network by ensuring that any two parties can always collude tobalance the overweening influence of a predominant third.

The Struggle for Profit:

Our system begins with a zero-sum battle between nodes and miners forthe “burn fees” paid by our nodes during the course of block-creation.This system works as follows:

Every time a node produces a block, it collects what profit it can andbundles the remaining fees into a “golden ticket” that contains acomputational puzzle for miners to solve, along with a vote on whetherto increase, decrease, or hold constant the share of the burn fee thatwill ultimately be distributed to miners instead of randomly to one ofthe bandwidth-providing nodes in the network (“paysplit”). Miners choosethemselves whether to solve these golden tickets, but finding a solutionis not enough, for should a miner succeed in solving one, it mustpropagate its solution back into the network as a fee-paying transactionfor inclusion in the very next block. As part of this solution, theminer may also make a secondary vote on whether to increase, decrease orhold constant the difficulty of the computational puzzle.

From these simple rules, a remarkable development ensues. The struggleto control the network in our two-player system requires a delicatedance between collusion and cooperation for both nodes and miners alike.For while nodes and miners both want to generate at least one solutionper golden ticket (because otherwise no one gets paid), their interestsotherwise diverge: miners prefer a high paysplit and high difficultylevel, while nodes prefer a low paysplit and low difficulty level. Whilethe reason for their disagreement over paysplit is obvious, that fortheir difference of opinion on mining difficulty is more subtle: minersprefer a high difficulty as that reduces the expected competition theyface from their peers and thus lowers the expected transaction fee theyneed to pay to induce nodes to prefer their solution (i.e., increasingtheir “take-home” share of the burn-fee); nodes meanwhile prefer a lowdifficulty rate not only because inter-miner competition increases thefees paid to them (and speeds up the pace of block production in theprocess, further securing their own income) but also because easiergolden tickets hold out the salivating prospect that nodes may be ableto select between multiple solutions and even pick one that rewardsthem.

According to some embodiments, it may be specified that once a goldenticket is solved by a miner and their solution is included by a node,the coinbase funds in the ticket are released to the two winners of theactivity, and the votes over paysplit and difficulty take effect. Andthis is another point where the Saito Network diverges from all existingcryptosystems. Strategically, the fact that votes in our network passback and forth between nodes and miners, and require implicit approvalfrom both groups to take effect, pushes us into a dynamic where nodesand miners must collude to protect their group interests (refusing toprocess the harmful votes of their counterparties) while using their ownclout to promote friendly blocks. Yet collusion is difficult becauseboth parties can also induce defection from the other side. Nodes canpad their golden ticket with extra funds to induce hashing support fromrenegade miners, while miners can propagate their solutions with higherfees to bribe support from nodes.

Whereas most cryptocurrencies work as technical games, the Saito Networkplays out as a zero-sum economic battle that is fundamentallyunsolvable. For the competition between our two groups is ultimately notdriven based on algorithmic factors so much as competitive pressures tocollude to protect long-term profits. Yet, because cartelizationinevitably pushes up profits and because our system is open-by-design,excessive profit cannot survive over the long-term: any side thatsucceeds in driving up class income will simultaneously invite themarket to provide more of the desired value, whether by inducing minersto enter the market, or inducing nodes to take advantage of a highpaysplit and “pull the trigger” on block production faster than theirpeers.

Our two-player system will eventually reach equilibrium at the pointwhere the security provided by miners is optimal given their relativecosts of collusion, but we acknowledge that this level is arbitrary andmay not reflect the amount of security (or bandwidth) desired by theapplications on the network, something especially relevant given thatour demand for security from miners decreases naturally as the volume oftransactions grows. And so, in some embodiments, we introduce a thirdparty whose market preferences ensure we hit an optimal economicdistribution of fees between nodes and miners. This third party consistsof the users who make up the network, and who are allowed by the networkto tag their transactions with an optional paysplit vote. Should auser-originated transaction contain a paysplit vote, the system insiststhat it can only be included in a block that votes in the samedirection. Users who choose to take sides in this ongoing strugglebetween nodes and miners thus sacrifice the reliability and speed oftransaction confirmation but gain marginal influence over the directionof the network by increasing the flow of capital to the party thatrepresents its interests in the central two-player system.

Our resulting three-party system is thus unsolvable. Miners are perhapsthe most influential party at small scale but lose influence as thevolume of transactions grows (adding a secondary level of security) andit becomes easier for nodes to collude (i.e., harder for miners tooperate their own nodes). And while the user/application influence isarguably weakest at the beginning, it ultimately becomes the mostpowerful influence on the network. And yet even with any group at itsapex, no particular group is ever fully ascendant, for any two playersin our system can always collude to protect the network from theoverweening influence of the third player.

Security in the Saito Network:

The dynamic described above is sufficient to secure the network. To makeattacks more expensive, we have nodes sign transactions as they passthem through the network, creating an unforgeable history of the patheach transaction takes to its point of confirmation. We also decreasethe amount of the transaction fee available to nodes with each hop atransaction takes through the network. And we specify that the node thatbenefits from the node portion of the golden ticket is selected from oneof the recorded participants according to a random input variableprovided as part of the mining solution.

These additional restrictions secure our network from common attacksvisible in other cryptocurrencies that are—oddly—not often recognized asattacks. In our system, for instance, transactions are naturallyvaluable to nodes that participate in the P2P network and useless toattackers that “lurk” on the edges. The fact that nodes must participatein the P2P network prevents an under-provision of connectivity anddefends the network against subtle attacks on open-access like thoseposed by the Bitcoin FIBRE network, a closed relay that benefitscolluding participants by undermining the profitability of those whomine on the P2P network. Sibyl attacks are also eliminated over time,because nodes themselves are incentivized to purge sibyls fromprofitable transaction paths; and in routing around them they increasethe robustness of the network as whole. Nodes pay other nodes forconnectivity in the form of valuable transaction flow, and transactionhoarding becomes a minority strategy since even the nodes that merelyparticipated in propagating a transaction have a chance at winning thenode-share of the golden ticket.

Security is also reinforced by the incentive structure of our system.For one, if network security falls too low, all parties can increase itby simply agreeing to pay miners more. Greater pay for miners encouragesthem to support the threatened chain in the long-run, while theincreased competition attracted by the fattened paysplit speeds up blockissuance on the threatened chain. Even in situations where the networkis not under active attack, the miner/node battle over the paysplit votealso serves a “canary in the coalmine” function, encouraging minersthemselves to issue an alternate chain if they control enough hashpowerto outcompete the main chain. Rather counterintuitively, it is thethreat and possibility of short-term miner attacks that forces thenetwork to keep its short-term security levels high enough that it isprotected from long-term attacks.

And since it is theoretically possible for a stealth chain to tweak itspaysplit and difficulty settings to lower its overall cost of blockproduction, our difficulty vote plays an equally important role inwarding off attacks. The reason for this is that because miners need tosolve “golden tickets” in order for the network to “approve” consensuschanges to the paysplit/difficulty settings, higher difficulty levelsforce attackers to devote more time and money to changing consensussettings. Properly understood, this offers a significant improvementover the security of Bitcoin's proof-of-work function, since our networkis protected not only by the need for attackers to have the financialresources to generate transaction volume, but also now by aminer-protected voting mechanism that requires significant hashpower toovercome. And it stipulates that the main chain—saving a total collapsein user, miner and node activity—will always be able to change its ownnetwork settings more quickly than attackers can manipulate their own.

There are many subtle attacks and responses that flow out of our system.But most responses are obvious. One unlikely but possible attack is anattacker burning capital to manipulate the burn fee of the main chainup, and then continuing to produce blocks on a lower-difficulty stealthchain at a faster pace than the main network can adjust its burn feedownwards again. This can be avoided by having nodes arbitrarily preferblocks that have a higher initial burn fee than their competitors at anyparticular block depth.

In any event, blockchain security is not just about protecting usersfrom reorganization attacks, it also implies censorship resistance. Andin this field, even a successful attack on the network is not able toaccomplish much beyond driving up the price of network token whileamassing the resources for an attack on the network. Extremely wealthyattackers can burn cash to censor transactions, but they can do this inBitcoin as well (by pricing out competing transactions). And even if anattack does overwrite a substantial portion of the blockchain, most ofthe transactions they overwrite can be almost immediately bundled ontothe end of the winning chain by the nodes that initially published them,where they then add to the security of the now-longest chain. And withusers shifting from direct payments to “inception payments” in the faceof greater network insecurity, and exchanges scrambling to increasetheir support for miners in the face of greater risk, losses from anyreorganization attack will disproportionately affect miners and nodes.Of course, the network can promptly recover unless the attacker hasessentially limitless financial resources, in which case users cansimply sell their tokens for profit and move to a network fork.

On a final note, we also observe that by forcing the network to dealwith only a finite amount of data at any time, we are also protectedfrom a huge class of software development risks. Whereas otherblockchains deal with enormous scalability problems driven by their needto develop custom code to enable scaling, the fact that the SaitoNetwork need only store a limited amount of transactional data (and canalways reduce this period as our transaction volume grows) keeps thesoftware requirements on the scale where existing industrial databasesand other components can be leveraged. In-memory databases already scaleinto the hundreds of terabytes, and there is no risk of serverrequirements expanding beyond the amount that an independent server canhandle, given the predictable income stream generated from the work ofstoring and processing transaction data.

These and other aspects or features of the various embodiments aredescribed in detail below with respect to FIGS. 2A-7C.

FIGS. 2A and 2B are graphical diagrams illustrating cost versus timecurves 200 and 200′ depicting required burn fees compared with totalcollected fees during regular operation and during a reorganizationattack, as part of a blockchain system that may be secured using proofof transactions, in accordance with various embodiments. FIG. 2C is agraphical diagram illustrating a curve showing the destruction of themoney supply over time in a blockchain that has a burn fee but nomechanism for re-injecting the burned tokens back into the network.

FIG. 2A depicts how the “proof of transactions” approach describedherein, which includes the implementation of a “burn fee,” works. TheY-axis measures the “burn fee” that must be paid to produce a block in ablockchain, while the X-axis measures the amount of time that has passedsince the last block was produced. As the amount of time since the lastblock was produced increases, the burn fee decreases in amount (asdepicted by curve 205 in FIG. 2A) while the number of transaction feesavailable to the blocks (and thus the total fees collected) increases(as depicted by curve 210 in FIG. 2A). As more time passes, additionaltransactions are expected to enter the network. The expected block timeis approximately at the intersection between these two curves 205 and210 (as depicted in FIG. 2A by the vertical dotted line), when itbecomes profitable for nodes to issue blocks.

FIG. 2B depicts how the dynamics of the various embodiments causeattacks to the system (e.g., reorganization attacks or the like) tobecome expensive. Attacking any blockchain requires producing moreblocks in a set amount of time than can be produced by the rest of thenetwork. This requires producing more blocks in the same period of time,or producing blocks at a faster pace. As FIG. 2B illustrates, given afixed burn fee (i.e., a burn fee value along the curve 205), increasingthe speed of block production might be achieved by shifting the supplycurve 210 upwards (as shown by curve 215), which requires the attackereither to have access to more fee-paying transactions than the rest ofthe network combined or to create their own fake transactions thatnonetheless pay real fees (e.g., spending capital, or the like). Asshown in FIG. 2B, with faster block production (as in a reorganizationattack), the cost of production of the block increases (as depicted bythe curved arrows shifting from the vertical and horizontal dotted linesto the vertical and horizontal dashed lines).

FIG. 2C depicts an issue with creating a proof-of-transactions-basedsystem that uses a burn fee to regulate the speed and cost of blockproduction. That is, the security of the system depends on production ofblocks by nodes being made costly. But, allowing nodes to burn capitalto produce blocks commits the network to a long-term deflationary spiralthat gradually destroys the economy. In time, the network runs out ofmoney and economic activity collapses.

The solution to this problem requires separating the act of injectingmoney into the blockchain ecosystem from the act of generating blocks.FIGS. 3B-7C below illustrate how fee and coinbase distribution might beused to achieve this solution.

FIG. 3A is a schematic diagram illustrating an example 300 of aconventional block including a plurality of transactions and a coinbase.In particular, FIG. 3A depicts a schematic of the structure of a block305 in a traditional blockchain, including a plurality of tokens 310(each of which might represent a transaction, a message, or data, or thelike) and a coinbase 315. In the traditional blockchain, the coinbase315—which represents new money being injected into the economy, as wellas implicitly representing the aggregate fees paid by the transactionsin the block—is part of the block 305 itself and is rewarded to the nodethat produces it.

This is a problem for the proof-of-transaction approach (as describedherein) as it works against the requirement that producing a block bemade expensive for the nodes in the peer-to-peer network. To solve thisissue, the act of producing a block should be separated from the act ofdistributing the funds that are pushed into the fee for producing theblock. FIG. 3B depicts a block that incorporates features that addressthis issue.

FIG. 3B is a schematic diagram illustrating an example 300′ of a blockincluding a plurality of transactions and a golden ticket, the blockbeing part of a blockchain system (in some non-limiting embodiments,part of the blockchain system of FIG. 1 or the like), in accordance withvarious embodiments. In particular, FIG. 3B depicts a schematic of thestructure of a block 320 in a blockchain in accordance with the variousembodiments. The block 320 might include a plurality of tokens 325(which is similar to tokens 310; each of which might represent atransaction, a message, or data, or the like) and a golden ticket 330(which is distinct from the coinbase 315). Rather than providing thenodes that produce the blocks with access to the fees and the coinbaseassociated with such blocks, the funds are instead bundled intocomputational puzzles that must be solved by other entities in thenetwork (e.g., miners) in order for the funds to be released. Thiscomputational puzzle is referred to herein as a “golden ticket.”

FIG. 4 is a schematic diagram illustrating a portion of a blockchain 400including a plurality of (consecutive) blocks 405 a-405 c (collectively,“blocks 405” or the like), each block including a plurality of tokens410 a, 410 b, or 410 c (collectively, “tokens 410” or the like) and agolden ticket 415 a, 415 b, or 415 c (collectively, “golden ticket 415”or the like), the blockchain 400 being part of a blockchain system (insome non-limiting embodiments, part of the blockchain system 100 of FIG.1 or the like), in accordance with various embodiments. Although notshown, the blocks 405 a-405 c might be located at the beginning of theblockchain, located at the end of the blockchain, or disposed somewherein between.

The non-limiting embodiment of FIG. 4 illustrates how a golden ticketcreates a two-player activity between a node and a miner. Nodes produceblocks 405, while miners solve the golden tickets 415 created by thenodes. Other nodes subsequently include the solutions 420 a or 420 b(collectively, “golden ticket solutions 420,” “solutions 420,” or thelike) to the golden tickets 415 into subsequent blocks—in some cases, asshown by golden ticket solution fields 425 b or 425 c (also 425 a;collectively, “golden ticket solution fields 425,” “solution fields425,” or the like). According to some embodiments, to create more feecompetition between miners if difficulty levels are too low, only onesolution to any golden ticket might be included in the blockchain.

FIG. 5 is a block diagram illustrating distribution of burn fees andcoinbase payout as part of a method 500 for securing a blockchain withproof-of-transactions, in accordance with various embodiments. In thenon-limiting embodiment of FIG. 5, method 500 illustrates how the “burnfees” and optional “coinbase” that are locked into the “golden ticket”are distributed based on the independent choices of the nodes and minersin the system. Importantly, the funds that are locked into the goldenticket are only released to the winning node and the miner after theminer has solved the golden ticket and after the solution has beenembedded or incorporated in the next block in the blockchain.

Referring to FIG. 5, method 500 might include producing, with a node, agolden ticket (block 505). Method 500 might further comprise determiningwhether a miner has solved the golden ticket (block 510). If not, theprocess returns to block 505. If so, the process continues to block 515,in which the method 500 might further comprise determining whether thesolution is embedded or incorporated in the next block in theblockchain. If not, the process returns to block 505. If so, the processcontinues to block 520, in which the method 500 might comprise splitting(and distributing) the burn fee and coinbase payout to the miner thatsolved the golden ticket and a randomly selected node in thepeer-to-peer network, in accordance with network consensus “paysplit.”Here, the randomly selected node might be a node selected from among aplurality of nodes within the peer-to-peer network that participate inpropagating or relaying a transaction (that once confirmed or validatedis included in a block of the blockchain), or the like.

In the event that a golden ticket is not solved, the funds that are lostto the network as a result can be recycled back into the economy throughfuture coinbase issuances attached to future golden tickets.

FIG. 6 is a block diagram illustrating paysplit voting and difficultyvoting as part of another method 600 for securing a blockchain withproof-of-transactions, in accordance with various embodiments. In thenon-limiting embodiment of FIG. 6, method 600 illustrates how votingdynamics of the various embodiments interact with the “golden ticket”system (i.e., how the network uses the “golden ticket” process to makecollective decisions about changing the consensus “paysplit” and“difficulty” levels for the network as a whole).

With reference to FIG. 6, method 600 might include producing, with anode, a golden ticket, the node making a “paysplit vote” (block 605).The “paysplit vote” might be a choice by nodes whether to increase, tohold constant, or to decrease the share of the golden ticket rewardallocated to miners. Method 600 might further comprise determiningwhether a miner has solved the golden ticket (block 610). If not, theprocess returns to block 605. If so, the process continues to block 615,in which the method 600 might comprise broadcasting, with the miner, thesolution, the miner making a “difficulty vote.” The “difficulty vote”might be a choice by miners whether to increase, to hold constant, or todecrease the difficulty of the mining puzzle. Method 600 might furthercomprise determining whether the solution is embedded or incorporated inthe next block in the blockchain (block 620). If not, the processreturns to block 605. If so, the process continues to block 625, inwhich the method 600 might comprise updating, with the network, paysplitand difficulty settings. The paysplit and difficulty votes only becomeeffective and contribute to changing the consensus settings once theyhave been included in the solution to a golden ticket and incorporatedin the blockchain.

Although not shown, according to some embodiments, users who initiate orparticipate in transactions might be provided with the ability to tagtheir transactions with an optional paysplit vote (either replacing thepaysplit vote of the node or contributing to the paysplit vote of thenode). In some cases, where the paysplit vote of the node and the usersare considered, an average of the vote might be used to determine aresultant paysplit vote that determines how much of the paysplit goes tothe miner who solves the golden ticket and how much goes to a randomlyselected node that participates in propagation of the transactions.

FIGS. 7A-7C (collectively, “FIG. 7”) are flow diagrams illustrating amethod 700 for securing a blockchain with proof-of-transactions, inaccordance with various embodiments. Method 700 of FIG. 7A continuesonto FIG. 7B following the circular marker denoted, “A,” which continuesonto FIG. 7C following the circular marker denoted, “B.”

While the techniques and procedures are depicted and/or described in acertain order for purposes of illustration, it should be appreciatedthat certain procedures may be reordered and/or omitted within the scopeof various embodiments. Moreover, while the method 700 illustrated byFIG. 7 can be implemented by or with (and, in some cases, are describedbelow with respect to) the systems, examples, or embodiments 100, 200,200′, 200″, 300′, 400, 500, and 600 of FIGS. 1, 2A, 2B, 2C, 3B, 4, 5,and 6, respectively (or components thereof), such methods may also beimplemented using any suitable hardware (or software) implementation.Similarly, while each of the systems, examples, or embodiments 100, 200,200′, 200″, 300′, 400, 500, and 600 of FIGS. 1, 2A, 2B, 2C, 3B, 4, 5,and 6, respectively (or components thereof), can operate according tothe method 700 illustrated by FIG. 7 (e.g., by executing instructionsembodied on a computer readable medium), the systems, examples, orembodiments 100, 200, 200′, 200″, 300′, 400, 500, and 600 of FIGS. 1,2A, 2B, 2C, 3B, 4, 5, and 6 can each also operate according to othermodes of operation and/or perform other suitable procedures

In the non-limiting embodiment of FIG. 7A, method 700, at block 705,might comprise embedding, by a first node among a plurality of nodes ina peer-to-peer blockchain network and into an unconfirmed transactionbeing propagated across said network for eventual inclusion in a block,a cryptographic signature and a network address that combines with othercryptographic signatures and network addresses that have been previouslyembedded in the unconfirmed transaction by one or more other nodes ofthe plurality of nodes in the blockchain network to create a chain ofsignatures that constitutes an independently-verifiable and unforgeablerecord of a routing path that the unconfirmed transaction takes as itpropagates across the peer-to-peer blockchain network.

In some embodiments, each node among the plurality of nodes in thepeer-to-peer blockchain network might be associated with a uniquepublic/private key pair and a network address. In some cases, the uniquepublic/private key pair might include, without limitation, a public keyand a private key. The network address of a node among the plurality ofnodes might contain information derived from the unique public/privatekey pair of the node, and a cryptographic signature of the node might begenerated by using the private key of the unique public/private key pairof the node to sign a network address of a subsequent node among theplurality of nodes to which the transaction is routed by the node.

According to some embodiments, the network address and the other networkaddresses might constitute a plurality of network addresses. A networkaddress associated with an originating node that originates thetransaction might not be included in the plurality of network addresses,based on a determination that information required to validate acryptographic signature associated with the originating node is alreadyincluded in the transaction. In some cases, the first node and thesecond node are the same node. Alternatively, the first node and thesecond node might be different nodes within the blockchain network.

Method 700 might further comprise quantifying, by one or more secondnodes among the plurality of nodes in the blockchain network and inaccordance with a set of consensus rules of a blockchain, a level ofdifficulty associated with producing a valid candidate block by reducingit to a burn fee, where the burn fee is a cost denominated in a value ofa token managed by the blockchain network (block 710) and quantifying,by the one or more second nodes and in accordance with the set ofconsensus rules of the blockchain, the value of one or more transactionsbeing included in a candidate block by reducing it to a burn value,where the burn value is a figure denominated in a value of a tokenmanaged by the blockchain network (block 715). At block 720, method 700might comprise determining, with the one or more second nodes and inaccordance with the set of consensus rules of the blockchain, whether asum of individual burn values of the one or more transactions that areincluded in the candidate block is equal to or greater than the burn feeof the candidate block. Method 700 might comprise, at block 725, basedon a determination that the sum of individual burn values of the one ormore transactions that are included in the candidate block is equal toor greater than the burn fee of the candidate block, determining, withthe one or more second nodes, that the candidate block is validaccording to the set of consensus rules of the blockchain.

According to some embodiments, the burn fee might be algorithmically setby at least one computing system in the blockchain network. In somecases, a burn fee needed for production of a block might decrease overtime in proportion to time elapsed since generation of a preceding blockin the blockchain. In some instances, a burn value of a transactionmight include a transaction fee paid by an originator of the transactionfor inclusion of its transaction in the blockchain. According to somecases, a burn value of a transaction might be adjusted depending onwhether the transaction contains a valid chain of embedded cryptographicsignatures establishing a route that the transaction has taken in itscourse of propagating across the blockchain network. According to someinstances, a burn value of a transaction might be adjusted downwarddepending on the number of hops that the transaction has made across theblockchain network, as measured by an embedded chain of cryptographicsignatures contained within the transaction that document its course oftransmission across the blockchain network. In some cases, the burnvalue of the transaction might be halved with each additional hop beyonda first hop that the transaction has made through the blockchain networkfrom its point of origin to its point of inclusion in a block.

In some embodiments, at least a portion of a difference in value betweena burn value of a transaction included in a block and a burn fee neededto produce a block, as measured in the value of the token managed by theblockchain network, might be granted to a node among the plurality ofnodes that produces the block as a form of payment for producing theblock. In some instances, at least a portion of the burn value of theone or more transactions included in the candidate block might beremoved from circulation and not transferred to a node that produced thecandidate block.

Method 700 might continue onto the process at optional block 730 in FIG.7B following the circular marker denoted, “A.” At optional block 730 inFIG. 7B (following the circular marker denoted, “A”), method 700 mightcomprise determining, with at least a majority of the plurality of nodesin the blockchain network, whether aggregate burn values of thetransactions included in a block are sufficient to pay for the burn feerequired for production of a block. At block 735, method 700 mightcomprise validating, with a third node among the plurality of nodes, thechain of signatures embedded in the transactions included in a block ofa blockchain to confirm that the block itself is valid in accordancewith a set of consensus rules of the blockchain. Method 700, at optionalblock 740, might comprise, based on a determination that the aggregateburn values of the transactions included in the block are sufficient topay for the burn fee required for the production of the block,determining, with the at least a majority of the plurality of nodes inthe blockchain network, that the block is valid and including, with theat least a majority of the plurality of nodes in the blockchain network,the block in a blockchain.

According to some embodiments, method 700 might further comprisepruning, by one or more fourth nodes among the plurality of nodes withinthe blockchain network, transaction slips in blocks in a blockchainpreceding an arbitrary block identified according to consensus rules ofthe blockchain (optional block 745); calculating, by the one or morefourth nodes among the plurality of nodes within the blockchain network,a value of all unspent tokens contained in all unpruned blocks precedingand including the last block being pruned (optional block 750); andadjusting a monetary policy of the blockchain network so that theblockchain network will reintroduce the unspent tokens as tokensallocated in future blocks (optional block 755). In some embodiments,the unspent tokens might be reintroduced back into the blockchainnetwork in a later block through use of golden tickets. Method 700 mightcontinue onto the process at block 760 in FIG. 7C following the circularmarker denoted, “B.”

At block 760 in FIG. 7C (following the circular marker denoted, “B”),method 700 might comprise generating, by a fifth node among theplurality of nodes in the blockchain network, a golden ticket thatcontains a computational puzzle. Method 700 might further comprisegenerating, by a sixth node among the plurality of nodes in theblockchain network, a solution to the computational puzzle in the goldenticket, where the solution to the computational puzzle is used toselect, in a manner that cannot be anticipated by the fifth nodegenerating the golden ticket, one or more network nodes among theplurality of nodes in the blockchain network (block 765). Method 700, atblock 770, might comprise broadcasting, by the sixth node, the solutionto the golden ticket throughout the blockchain network, the solutionbeing included in a subsequent block that is produced and validated bythe blockchain network. Method 700 might further comprise, at block 775,distributing blockchain tokens to the one or more network nodes that areselected using the solution to the computational puzzle in the goldenticket.

In some embodiments, the fifth node and the sixth node might be the samenode. Alternatively, the fifth node and the sixth node might bedifferent nodes. In some cases, the golden ticket might be at least oneof included in a block published for inclusion in a blockchain orautomatically associated with the block, or the like. In some instances,the golden ticket might comprise a random number that is created usingdata associated with the block. In some cases, the random number mightcomprise a cryptographic hash of data content contained within theblock. In some instances, the solution to the golden ticket might beincluded in a block immediately following the block in which the goldenticket is included was published.

Merely by way of example, according to some embodiments, any validblockchain might contain one or more golden tickets, each of which maybe solved only once. In some cases, a block might contain only onesolution to any particular golden ticket. In some instances, a blockmight contain only one golden ticket. In some cases, a block mightcontain a solution to only one golden ticket. In some instances, a blockmight be considered to be invalid based on a determination that theblock contains a golden ticket solution that is invalid.

In some embodiments, the solution to the computational puzzle in thegolden ticket might comprise a product of a computationally difficultchallenge that is independently verifiable by other nodes in theblockchain network. In some cases, the solution to the computationalpuzzle in the golden ticket that is generated by the sixth node might begenerated based on a hash of data associated with the golden ticket thatmeets validity criteria as defined in consensus rules of the blockchain.

In some instances, the solution to the computational puzzle in thegolden ticket is used to select one or more network nodes from a subsetof network nodes among the plurality of nodes in the blockchain networkthat are identified as being valuable routing nodes with regard toproduction of a block containing the golden ticket. According to someembodiments, routing nodes might be determined to be valuable based atleast in part on data from a list of active routing nodes recordedwithin chains of cryptographic signatures and addresses embedded withintransactions that are contained in the block containing the goldenticket. In some cases, the list of active routing nodes might berestricted to network nodes that are recorded within chains ofcryptographic signatures and addresses embedded within transactions thatare included within the same block that contains a golden ticket. Insome instances, a likelihood that the one or more network nodes areselected might be weighted according to a determination that the one ormore network nodes are each perceived to contribute to health of theblockchain network as a whole, as measured based on consensus rules ofthe blockchain and using factors including at least one of a value of atransaction fee associated with each transaction or a burn value of atransaction.

According to some embodiments, an amount of tokens allocated through useof golden tickets might be equivalent to transaction fees paid in ablock containing a golden ticket that contains a computational puzzle towhich a solution has been generated. In alternative embodiments, anamount of tokens allocated through use of golden tickets might beequivalent to transaction fees paid in a block containing a goldenticket that contains a computational puzzle to which a solution has beengenerated, minus any value tokens allocated to a network node thatgenerates the block containing the golden ticket, and adjusted to beplus or minus another amount determined by consensus rules of theblockchain to maintain a consistent money supply.

In some cases, tokens allocated through use of golden tickets might besplit between one or more network nodes that have provided solutions togolden tickets (“lucky miners”) and one or more nodes selected by one ormore solutions to the golden tickets (“lucky nodes”). In some instances,votes to adjust variables contained in one of a block, the goldenticket, or the solution might be used to adjust a value of consensusvariables once the solution to the golden ticket is included in theblock and tokens are allocated to the lucky node and lucky miner in theblockchain network. In some cases, distribution of the tokens splitbetween lucky miners and lucky nodes might be determined by a paysplitvariable managed according to consensus rules of the blockchain. In someembodiments, the paysplit variable might be adjusted to direct one of agreater proportion or a lesser proportion of the blockchain tokens beingdistributed to the one or more network nodes that are selected. In somecases, the method 700 might further comprise embedding, within one of ablock or a golden ticket, a variable that indicates whether to increase,to hold constant, or to decrease a value of the paysplit variablemanaged according to the consensus rules of the blockchain. In someinstances, blocks that contain a vote of the block indicating one of todecrease or to increase a value of the paysplit variable might includeonly transactions that are consistent with the vote of the blockindicating the one of to decrease or to increase the value of thepaysplit variable.

According to some embodiments, method 700 might further compriseembedding, within a transaction, a variable that indicates whether toincrease, to hold constant, or to decrease a value of the paysplitvariable managed according to the consensus rules of the blockchain. Insome cases, a difficulty level of the computational puzzle might bedetermined using a difficulty variable managed according to consensusrules of the blockchain. In some instances, the difficulty variablemight be adjusted to make selection of which network nodes to provideeligible solutions one of more difficult or less difficult, where ahigher difficulty might correspond to a reduced set of nodes that willbe considered eligible to generate solutions under the consensus rulesof the blockchain. In some cases, method 700 might further compriseembedding, within a solution to a golden ticket, a variable thatindicates whether to increase, to hold constant, or to decrease a valueof the difficulty variable managed according to the consensus rules ofthe blockchain.

In some embodiments, the computational puzzle might establish atwo-player chain, where the two-player chain established by thecomputational puzzles might be extended into a chain with an arbitrarynumber of participants, to perform at least one of providing additionalrandomness or splitting allocation of tokens into a finer distributionsettling to more participants in the blockchain network. In someinstances, the method 700 might further comprise embedding, within oneof a block or a golden ticket, a variable that indicates whether todecrease, to hold constant, or to increase a value of a networkconsensus variable (“vote of the block” or “vote of the golden ticket”).In some cases, blocks that contain a vote of the block indicating one ofto decrease or to increase a value of the network consensus variablemight include only transactions that are consistent with the vote of theblock indicating the one of to decrease or to increase the value of thenetwork consensus variable.

According to some embodiments, method 700 might further compriseembedding, within a solution to a golden ticket, a variable thatindicates whether to decrease, to hold constant, or to increase a valueof a network consensus variable (“vote of the golden ticket”).Alternatively, or additionally, method 700 might further compriseembedding, within a transaction, a variable that indicates whether todecrease, to hold constant, or to increase a value of a networkconsensus variable (“vote of the transaction”).

FIGS. 8A and 8B (collectively, “FIG. 8”) are flow diagrams illustratinganother method 800 for securing a blockchain with proof-of-transactions,in accordance with various embodiments.

While the techniques and procedures are depicted and/or described in acertain order for purposes of illustration, it should be appreciatedthat certain procedures may be reordered and/or omitted within the scopeof various embodiments. Moreover, while the method 800 illustrated byFIG. 8 can be implemented by or with (and, in some cases, are describedbelow with respect to) the systems, examples, or embodiments 100, 200,200′, 200″, 300′, 400, 500, and 600 of FIGS. 1, 2A, 2B, 2C, 3B, 4, 5,and 6, respectively (or components thereof), such methods may also beimplemented using any suitable hardware (or software) implementation.Similarly, while each of the systems, examples, or embodiments 100, 200,200′, 200″, 300′, 400, 500, and 600 of FIGS. 1, 2A, 2B, 2C, 3B, 4, 5,and 6, respectively (or components thereof), can operate according tothe method 800 illustrated by FIG. 8 (e.g., by executing instructionsembodied on a computer readable medium), the systems, examples, orembodiments 100, 200, 200′, 200″, 300′, 400, 500, and 600 of FIGS. 1,2A, 2B, 2C, 3B, 4, 5, and 6 can each also operate according to othermodes of operation and/or perform other suitable procedures

In the non-limiting embodiment of FIG. 8A, method 800 might comprisequantifying, by one or more first nodes among a plurality of nodes in ablockchain network and in accordance with a set of consensus rules of ablockchain, a level of difficulty associated with producing a validcandidate block by reducing it to a burn fee, where the burn fee is acost denominated in a value of a token managed by the blockchain network(block 805) and quantifying, by the one or more first nodes and inaccordance with the set of consensus rules of the blockchain, the valueof one or more transactions being included in a candidate block byreducing it to a burn value, where the burn value is a figuredenominated in a value of a token managed by the blockchain network(block 810). At block 815, method 800 might comprise determining, withthe one or more first nodes and in accordance with the set of consensusrules of the blockchain, whether a sum of individual burn values of theone or more transactions that are included in the candidate block isequal to or greater than the burn fee of the candidate block. Method 800might comprise, at block 820, based on a determination that the sum ofindividual burn values of the one or more transactions that are includedin the candidate block is equal to or greater than the burn fee of thecandidate block, determining, with the one or more first nodes, that thecandidate block is valid according to the set of consensus rules of theblockchain.

According to some embodiments, the burn fee might be algorithmically setby at least one computing system in the blockchain network. In somecases, a burn fee needed for production of a block might decrease overtime in proportion to time elapsed since generation of a preceding blockin the blockchain. In some instances, a burn value of a transactionmight include a transaction fee paid by an originator of the transactionfor inclusion of its transaction in the blockchain. According to somecases, a burn value of a transaction might be adjusted depending onwhether the transaction contains a valid chain of embedded cryptographicsignatures establishing a route that the transaction has taken in itscourse of propagating across the blockchain network. According to someinstances, a burn value of a transaction might be adjusted downwarddepending on the number of hops that the transaction has made across theblockchain network, as measured by an embedded chain of cryptographicsignatures contained within the transaction that document its course oftransmission across the blockchain network. In some cases, the burnvalue of the transaction might be halved with each additional hop beyonda first hop that the transaction has made through the blockchain networkfrom its point of origin to its point of inclusion in a block.

In some embodiments, at least a portion of a difference in value betweena burn value of a transaction included in a block and a burn fee neededto produce a block, as measured in the value of the token managed by theblockchain network, might be granted to a node among the plurality ofnodes that produces the block as a form of payment for producing theblock. In some instances, at least a portion of the burn value of theone or more transactions included in the candidate block might beremoved from circulation and not transferred to a node that produced thecandidate block.

At optional block 825, method 800 might comprise determining, with atleast a majority of the plurality of nodes in the blockchain network,whether aggregate burn values of the transactions included in a blockare sufficient to pay for the burn fee required for production of ablock. Method 800, at optional block 830, might comprise, based on adetermination that the aggregate burn values of the transactionsincluded in the block are sufficient to pay for the burn fee requiredfor the production of the block, determining, with the at least amajority of the plurality of nodes in the blockchain network, that theblock is valid and including, with the at least a majority of theplurality of nodes in the blockchain network, the block in a blockchain.

With reference to FIG. 8B, method 800 might further comprisecalculating, by the one or more second nodes among the plurality ofnodes within the blockchain network, a value of all unspent tokenscontained in all unpruned blocks preceding (optional block 835);adjusting a monetary policy of the blockchain network so that theblockchain network will reintroduce the unspent tokens as tokensallocated in future blocks (optional block 840); and pruning, by one ormore second nodes among the plurality of nodes within the blockchainnetwork, transaction slips in blocks in a blockchain preceding anarbitrary block identified according to consensus rules of theblockchain (optional block 845). In some embodiments, the unspent tokensmight be reintroduced back into the blockchain network in a later blockthrough use of golden tickets

Exemplary System and Hardware Implementation

FIG. 9 is a block diagram illustrating an exemplary computer or systemhardware architecture, in accordance with various embodiments. FIG. 9provides a schematic illustration of one embodiment of a computer system900 of the service provider system hardware that can perform the methodsprovided by various other embodiments, as described herein, and/or canperform the functions of computer or hardware system (i.e., computingsystem 105, nodes 110, user devices 130 a-130 n and 135 a-135 n, etc.),as described above. It should be noted that FIG. 9 is meant only toprovide a generalized illustration of various components, of which oneor more (or none) of each may be utilized as appropriate. FIG. 9,therefore, broadly illustrates how individual system elements may beimplemented in a relatively separated or relatively more integratedmanner.

The computer or hardware system 900—which might represent an embodimentof the computer or hardware system (i.e., computing system 105, nodes110, user devices 130 a-130 n and 135 a-135 n, etc.), described abovewith respect to FIGS. 1-8—is shown comprising hardware elements that canbe electrically coupled via a bus 905 (or may otherwise be incommunication, as appropriate). The hardware elements may include one ormore processors 910, including, without limitation, one or moregeneral-purpose processors and/or one or more special-purpose processors(such as microprocessors, digital signal processing chips, graphicsacceleration processors, and/or the like); one or more input devices915, which can include, without limitation, a mouse, a keyboard, and/orthe like; and one or more output devices 920, which can include, withoutlimitation, a display device, a printer, and/or the like.

The computer or hardware system 900 may further include (and/or be incommunication with) one or more storage devices 925, which can comprise,without limitation, local and/or network accessible storage, and/or caninclude, without limitation, a disk drive, a drive array, an opticalstorage device, solid-state storage device such as a random accessmemory (“RAM”) and/or a read-only memory (“ROM”), which can beprogrammable, flash-updateable, and/or the like. Such storage devicesmay be configured to implement any appropriate data stores, including,without limitation, various file systems, database structures, and/orthe like.

The computer or hardware system 900 might also include a communicationssubsystem 930, which can include, without limitation, a modem, a networkcard (wireless or wired), an infra-red communication device, a wirelesscommunication device and/or chipset (such as a Bluetooth™ device, an802.11 device, a WiFi device, a WiMax device, a WWAN device, cellularcommunication facilities, etc.), and/or the like. The communicationssubsystem 930 may permit data to be exchanged with a network (such asthe network described below, to name one example), with other computeror hardware systems, and/or with any other devices described herein. Inmany embodiments, the computer or hardware system 900 will furthercomprise a working memory 935, which can include a RAM or ROM device, asdescribed above.

The computer or hardware system 900 also may comprise software elements,shown as being currently located within the working memory 935,including an operating system 940, device drivers, executable libraries,and/or other code, such as one or more application programs 945, whichmay comprise computer programs provided by various embodiments(including, without limitation, hypervisors, VMs, and the like), and/ormay be designed to implement methods, and/or configure systems, providedby other embodiments, as described herein. Merely by way of example, oneor more procedures described with respect to the method(s) discussedabove might be implemented as code and/or instructions executable by acomputer (and/or a processor within a computer); in an aspect, then,such code and/or instructions can be used to configure and/or adapt acomputer (or other device), in particular a general purpose computer, toperform one or more operations in accordance with the described methods.

A set of these instructions and/or code might be encoded and/or storedon a computer readable medium, in particular, a non-transitory computerreadable storage medium, such as the storage device(s) 925 describedabove. In some cases, the storage medium might be incorporated within acomputer system, such as the system 900. In other embodiments, thestorage medium might be separate from a computer system (i.e., aremovable medium, such as a compact disc, etc.), and/or provided in aninstallation package, such that the storage medium can be used toprogram, configure, and/or adapt a computer such as a general purposecomputer with the instructions/code stored thereon. These instructionsmight take the form of executable code, which is executable by thecomputer or hardware system 900 and/or might take the form of sourceand/or installable code, which, upon compilation and/or installation onthe computer or hardware system 900 (e.g., using any of a variety ofgenerally available compilers, installation programs,compression/decompression utilities, etc.) then takes the form ofexecutable code.

It will be apparent to those skilled in the art that substantialvariations may be made in accordance with specific requirements. Forexample, customized hardware (such as programmable logic controllers,field-programmable gate arrays, application-specific integratedcircuits, and/or the like) might also be used, and/or particularelements might be implemented in hardware, software (including portablesoftware, such as applets, etc.), or both. Further, connection to othercomputing devices such as network input/output devices may be employed.

As mentioned above, in one aspect, some embodiments may employ acomputer or hardware system (such as the computer or hardware system900) to perform methods in accordance with various embodiments of theinvention. According to a set of embodiments, some or all of theprocedures of such methods are performed by the computer or hardwaresystem 900 in response to processor 910 executing one or more sequencesof one or more instructions (which might be incorporated into theoperating system 940 and/or other code, such as an application program945) contained in the working memory 935. Such instructions may be readinto the working memory 935 from another computer readable medium, suchas one or more of the storage device(s) 925. Merely by way of example,execution of the sequences of instructions contained in the workingmemory 935 might cause the processor(s) 910 to perform one or moreprocedures of the methods described herein.

The terms “machine readable medium” and “computer readable medium,” asused herein, refer to any medium that participates in providing datathat causes a machine to operate in a specific fashion. In an embodimentimplemented using the computer or hardware system 900, various computerreadable media might be involved in providing instructions/code toprocessor(s) 910 for execution and/or might be used to store and/orcarry such instructions/code (e.g., as signals). In manyimplementations, a computer readable medium is a non-transitory,physical, and/or tangible storage medium. In some embodiments, acomputer readable medium may take many forms, including, but not limitedto, non-volatile media, volatile media, or the like. Non-volatile mediaincludes, for example, optical and/or magnetic disks, such as thestorage device(s) 925. Volatile media includes, without limitation,dynamic memory, such as the working memory 935. In some alternativeembodiments, a computer readable medium may take the form oftransmission media, which includes, without limitation, coaxial cables,copper wire, and fiber optics, including the wires that comprise the bus905, as well as the various components of the communication subsystem930 (and/or the media by which the communications subsystem 930 providescommunication with other devices). In an alternative set of embodiments,transmission media can also take the form of waves (including withoutlimitation radio, acoustic, and/or light waves, such as those generatedduring radio-wave and infra-red data communications).

Common forms of physical and/or tangible computer readable mediainclude, for example, a floppy disk, a flexible disk, a hard disk,magnetic tape, or any other magnetic medium, a CD-ROM, any other opticalmedium, punch cards, paper tape, any other physical medium with patternsof holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chipor cartridge, a carrier wave as described hereinafter, or any othermedium from which a computer can read instructions and/or code.

Various forms of computer readable media may be involved in carrying oneor more sequences of one or more instructions to the processor(s) 910for execution. Merely by way of example, the instructions may initiallybe carried on a magnetic disk and/or optical disc of a remote computer.A remote computer might load the instructions into its dynamic memoryand send the instructions as signals over a transmission medium to bereceived and/or executed by the computer or hardware system 900. Thesesignals, which might be in the form of electromagnetic signals, acousticsignals, optical signals, and/or the like, are all examples of carrierwaves on which instructions can be encoded, in accordance with variousembodiments of the invention.

The communications subsystem 930 (and/or components thereof) generallywill receive the signals, and the bus 905 then might carry the signals(and/or the data, instructions, etc. carried by the signals) to theworking memory 935, from which the processor(s) 905 retrieves andexecutes the instructions. The instructions received by the workingmemory 935 may optionally be stored on a storage device 925 eitherbefore or after execution by the processor(s) 910.

As noted above, a set of embodiments comprises methods and systems forimplementing blockchain transactions, and, more particularly, tomethods, systems, and apparatuses for securing a blockchain withproof-of-transactions. FIG. 10 illustrates a schematic diagram of asystem 1000 that can be used in accordance with one set of embodiments.The system 1000 can include one or more user computers, user devices, orcustomer devices 1005. A user computer, user device, or customer device1005 can be a general purpose personal computer (including, merely byway of example, desktop computers, tablet computers, laptop computers,handheld computers, and the like, running any appropriate operatingsystem, several of which are available from vendors such as Apple,Microsoft Corp., and the like), cloud computing devices, a server(s),and/or a workstation computer(s) running any of a variety ofcommercially-available UNIX™ or UNIX-like operating systems. A usercomputer, user device, or customer device 1005 can also have any of avariety of applications, including one or more applications configuredto perform methods provided by various embodiments (as described above,for example), as well as one or more office applications, databaseclient and/or server applications, and/or web browser applications.Alternatively, a user computer, user device, or customer device 1005 canbe any other electronic device, such as a thin-client computer,Internet-enabled mobile telephone, and/or personal digital assistant,capable of communicating via a network (e.g., the network(s) 1010described below) and/or of displaying and navigating web pages or othertypes of electronic documents. Although the exemplary system 1000 isshown with two user computers, user devices, or customer devices 1005,any number of user computers, user devices, or customer devices can besupported.

Certain embodiments operate in a networked environment, which caninclude a network(s) 1010. The network(s) 1010 can be any type ofnetwork familiar to those skilled in the art that can support datacommunications using any of a variety of commercially-available (and/orfree or proprietary) protocols, including, without limitation, TCP/IP,SNA™, IPX™, AppleTalk™, and the like. Merely by way of example, thenetwork(s) 1010 (similar to network(s) 120 a-120 n, 125, and 140 a-140 nof FIG. 1, or the like) can each include a local area network (“LAN”),including, without limitation, a fiber network, an Ethernet network, aToken-Ring™ network, and/or the like; a wide-area network (“WAN”); awireless wide area network (“WWAN”); a virtual network, such as avirtual private network (“VPN”); the Internet; an intranet; an extranet;a public switched telephone network (“PSTN”); an infra-red network; awireless network, including, without limitation, a network operatingunder any of the IEEE 802.11 suite of protocols, the Bluetooth™ protocolknown in the art, and/or any other wireless protocol; and/or anycombination of these and/or other networks. In a particular embodiment,the network might include an access network of the service provider(e.g., an Internet service provider (“ISP”)). In another embodiment, thenetwork might include a core network of the service provider, and/or theInternet.

Embodiments can also include one or more server computers 1015. Each ofthe server computers 1015 may be configured with an operating system,including, without limitation, any of those discussed above, as well asany commercially (or freely) available server operating systems. Each ofthe servers 1015 may also be running one or more applications, which canbe configured to provide services to one or more clients 1005 and/orother servers 1015.

Merely by way of example, one of the servers 1015 might be a dataserver, a web server, a cloud computing device(s), or the like, asdescribed above. The data server might include (or be in communicationwith) a web server, which can be used, merely by way of example, toprocess requests for web pages or other electronic documents from usercomputers 1005. The web server can also run a variety of serverapplications, including HTTP servers, FTP servers, CGI servers, databaseservers, Java servers, and the like. In some embodiments of theinvention, the web server may be configured to serve web pages that canbe operated within a web browser on one or more of the user computers1005 to perform methods of the invention.

The server computers 1015, in some embodiments, might include one ormore application servers, which can be configured with one or moreapplications accessible by a client running on one or more of the clientcomputers 1005 and/or other servers 1015. Merely by way of example, theserver(s) 1015 can be one or more general purpose computers capable ofexecuting programs or scripts in response to the user computers 1005and/or other servers 1015, including, without limitation, webapplications (which might, in some cases, be configured to performmethods provided by various embodiments). Merely by way of example, aweb application can be implemented as one or more scripts or programswritten in any suitable programming language, such as Java™, C, C#™ orC++, and/or any scripting language, such as Perl, Python, or TCL, aswell as combinations of any programming and/or scripting languages. Theapplication server(s) can also include database servers, including,without limitation, those commercially available from Oracle™,Microsoft™, Sybase™, IBM™, and the like, which can process requests fromclients (including, depending on the configuration, dedicated databaseclients, API clients, web browsers, etc.) running on a user computer,user device, or customer device 1005 and/or another server 1015. In someembodiments, an application server can perform one or more of theprocesses for implementing blockchain transactions, and, moreparticularly, to methods, systems, and apparatuses for securing ablockchain with proof-of-transactions, as described in detail above.Data provided by an application server may be formatted as one or moreweb pages (comprising HTML, JavaScript, etc., for example) and/or may beforwarded to a user computer 1005 via a web server (as described above,for example). Similarly, a web server might receive web page requestsand/or input data from a user computer 1005 and/or forward the web pagerequests and/or input data to an application server. In some cases, aweb server may be integrated with an application server.

In accordance with further embodiments, one or more servers 1015 canfunction as a file server and/or can include one or more of the files(e.g., application code, data files, etc.) necessary to implementvarious disclosed methods, incorporated by an application running on auser computer 1005 and/or another server 1015. Alternatively, as thoseskilled in the art will appreciate, a file server can include allnecessary files, allowing such an application to be invoked remotely bya user computer, user device, or customer device 1005 and/or server1015.

It should be noted that the functions described with respect to variousservers herein (e.g., application server, database server, web server,file server, etc.) can be performed by a single server and/or aplurality of specialized servers, depending on implementation-specificneeds and parameters.

In certain embodiments, the system can include one or more databases1020 a-1020 n (collectively, “databases 1020”). The location of each ofthe databases 1020 is discretionary: merely by way of example, adatabase 1020 a might reside on a storage medium local to (and/orresident in) a server 1015 a (and/or a user computer, user device, orcustomer device 1005). Alternatively, a database 1020 n can be remotefrom any or all of the computers 1005, 1015, so long as it can be incommunication (e.g., via the network 1010) with one or more of these. Ina particular set of embodiments, a database 1020 can reside in astorage-area network (“SAN”) familiar to those skilled in the art.(Likewise, any necessary files for performing the functions attributedto the computers 1005, 1015 can be stored locally on the respectivecomputer and/or remotely, as appropriate.) In one set of embodiments,the database 1020 can be a relational database, such as an Oracledatabase, that is adapted to store, update, and retrieve data inresponse to SQL-formatted commands. The database might be controlledand/or maintained by a database server, as described above, for example.

According to some embodiments, system 1000 might further comprise acomputing system 1025 (similar to computing system 105 of FIG. 1, or thelike), one or more nodes 1030 a-1030 n (collectively, “nodes 1030” orthe like; similar to nodes 110 of FIG. 1, or the like), network(s) 1035(similar to network(s) 120 a-120 n or 125 of FIG. 1, or the like), oneor more peer data storage systems 1040 (similar to peer data storagesystems #1-#N 115 ₁-115 _(N) of FIG. 1, or the like), and/or the like.

In operation, the plurality of nodes 1030 might propagate an unconfirmedtransaction across at least one of the networks 1035. The computingsystem 1025 or a first node 1030 a among the plurality of nodes 1030might embed, into the unconfirmed transaction, a cryptographic signatureand a network address that combines with other cryptographic signaturesand network addresses that have been previously embedded in theunconfirmed transaction by one or more other nodes of the plurality ofnodes in the blockchain network to create a chain of signatures thatconstitutes an independently-verifiable and unforgeable record of arouting path that the unconfirmed transaction takes as it propagatesacross the peer-to-peer blockchain network. The computing system 1025 ora second node 1030 b (not shown) among the plurality of nodes 1030 mightvalidate the chain of signatures embedded in the transactions includedin a block of a blockchain to confirm that the block itself is valid inaccordance with a set of consensus rules of the blockchain.

In some embodiments, the computing system 1025 or one or more thirdnodes 1030 c (not shown) among the plurality of nodes 1030 mightquantify a level of difficulty associated with producing a validcandidate block by reducing it to a burn fee, in accordance with a setof consensus rules of a blockchain. In some cases, the burn fee might bea cost denominated in a value of a token managed by the blockchainnetwork. According to some embodiments, the computing system 1025 or oneor more third nodes 1030 c might quantify the value of one or moretransactions being included in a candidate block by reducing it to aburn value, in accordance with the set of consensus rules of theblockchain. In some instances, the burn value might be a figuredenominated in a value of a token managed by the blockchain network. Insome embodiments, the computing system 1025 or one or more third nodes1030 c might determine whether a sum of individual burn values of theone or more transactions that are included in the candidate block isequal to or greater than the burn fee of the candidate block, inaccordance with the set of consensus rules of the blockchain. Based on adetermination that the sum of individual burn values of the one or moretransactions that are included in the candidate block is equal to orgreater than the burn fee of the candidate block, the computing system1025 or one or more third nodes 1030 c might determine that thecandidate block is valid according to the set of consensus rules of theblockchain.

In some embodiments, at least a majority of the plurality of nodes 1030in the blockchain network 1035 might determine whether aggregate burnvalues of the transactions included in a block are sufficient to pay forthe burn fee required for production of a block. Based on adetermination that the aggregate burn values of the transactionsincluded in the block are sufficient to pay for the burn fee requiredfor the production of the block, the at least a majority of theplurality of nodes 1030 might determine that the block is valid andmight include the block in a blockchain. In some instances, at least aportion of a difference in value between a burn value of a transactionincluded in a block and a burn fee needed to produce a block, asmeasured in the value of the token managed by the blockchain network,might be granted to a node among the plurality of nodes that producesthe block as a form of payment for producing the block. In some cases,at least a portion of the burn value of the one or more transactionsincluded in the candidate block might be removed from circulation andnot transferred to a node that produced the candidate block.

According to some embodiments, the computing system 1025 or one or morefourth nodes 1030 d (not shown) among the plurality of nodes 1030 withinthe blockchain network 1035 might prune transaction slips in blocks in ablockchain preceding an arbitrary block identified according toconsensus rules of the blockchain, and might calculate a value of allunspent tokens contained in all unpruned blocks preceding and includingthe last block being pruned. The computing system 1025 or at least onenode among the plurality of nodes 1030 might adjust a monetary policy ofthe blockchain network so that the blockchain network would reintroducethe unspent tokens as tokens allocated in future blocks. In some cases,the unspent tokens might be reintroduced back into the blockchainnetwork in a later block through use of golden tickets.

In some embodiments, the computing system 1025 or a fifth node 1030 e(not shown) among the plurality of nodes 1030 in the blockchain networkmight generate a golden ticket that contains a computational puzzle. Thecomputing system 1025 or a sixth node 1030 f (not shown) among theplurality of nodes 1030 in the blockchain network might generate asolution to the computational puzzle in the golden ticket, where thesolution to the computational puzzle might be used to select one or morenetwork nodes among the plurality of nodes 1030 in the blockchainnetwork, in a manner that cannot be anticipated by the computing system1025 or the fifth node 1030 e generating the golden ticket. In someinstances, at least two of the first node 1030 a, the second node 1030b, the third node 1030 c, the fourth node 1030 d, the fifth node 1030 e,the sixth node 1030 f, and/or the computing system 1025 might be thesame node. Alternatively, the first node 1030 a, the second node 1030 b,the third node 1030 c, the fourth node 1030 d, the fifth node 1030 e,the sixth node 1030 f, and/or the computing system 1025 might bedifferent nodes. In some embodiments, the golden ticket might be atleast one of included in a block published for inclusion in a blockchainor automatically associated with the block, and/or the like. In somecases, the golden ticket might include, without limitation, a randomnumber that is created using data associated with the block. In someinstances, the random number might comprise a cryptographic hash of datacontent contained within the block. In some cases, the solution to thegolden ticket might be included in a block immediately following theblock in which the golden ticket is included was published. In someinstances, any valid blockchain might contain one or more goldentickets, each of which may be solved only once.

These and other functions of the system 1000 (and its components) aredescribed in greater detail above with respect to FIGS. 1-8.

In the present disclosure, “nodes” can be considered “computer nodes,”“lucky miners” can be considered “solution-providing miners,” “luckynodes” can be considered “solution-selected nodes,” a “vote of theblock” can be considered a “variable embedded in the block,” a “vote ofthe golden ticket” can be considered a “variable embedded in the goldenticket,” a “vote of the transaction” can be considered a “variableembedded in the transaction,” and a “golden ticket” can be considered adata structure containing a computational puzzle to be solved bysolution-providing miners, the solution being used to select networknodes in the blockchain as described above.

The accompanying method claims can be considered computer-implementedmethods.

Although the accompanying claims are presented with single dependencies,this is to satisfy the requirements of certain jurisdictions. Unless itis clear that the features are presented as incompatible alternatives,the features of any dependent claim can be combined with those of anyone or more dependent claims before it, together with the features ofthe independent claim upon which these dependent claims depend. In otherwords, the dependent claims can be combined as if they contain multipledependencies, as are allowed in some jurisdictions, and multipledependencies may be inserted in the dependent claims.

One aspect provides a computer readable medium comprising computerexecutable instructions which, when executed by a computer, cause thecomputer to perform the method of any of the accompanying method claimsor a relevant part of the method.

While certain features and aspects have been described with respect toexemplary embodiments, one skilled in the art will recognize thatnumerous modifications are possible. For example, the methods andprocesses described herein may be implemented using hardware components,software components, and/or any combination thereof. Further, whilevarious methods and processes described herein may be described withrespect to particular structural and/or functional components for easeof description, methods provided by various embodiments are not limitedto any particular structural and/or functional architecture but insteadcan be implemented on any suitable hardware, firmware and/or softwareconfiguration. Similarly, while certain functionality is ascribed tocertain system components, unless the context dictates otherwise, thisfunctionality can be distributed among various other system componentsin accordance with the several embodiments.

Moreover, while the procedures of the methods and processes describedherein are described in a particular order for ease of description,unless the context dictates otherwise, various procedures may bereordered, added, and/or omitted in accordance with various embodiments.Moreover, the procedures described with respect to one method or processmay be incorporated within other described methods or processes;likewise, system components described according to a particularstructural architecture and/or with respect to one system may beorganized in alternative structural architectures and/or incorporatedwithin other described systems. Hence, while various embodiments aredescribed with—or without—certain features for ease of description andto illustrate exemplary aspects of those embodiments, the variouscomponents and/or features described herein with respect to a particularembodiment can be substituted, added and/or subtracted from among otherdescribed embodiments, unless the context dictates otherwise.Consequently, although several exemplary embodiments are describedabove, it will be appreciated that the invention is intended to coverall modifications and equivalents within the scope of the followingclaims.

What is claimed is:
 1. A method, comprising: pruning, by one or morefirst nodes among a plurality of nodes within a blockchain network,transaction slips in blocks in a blockchain preceding an arbitrary blockidentified according to consensus rules of the blockchain; calculating,by the one or more first nodes among the plurality of nodes within theblockchain network, a value of all unspent tokens contained in allunpruned blocks preceding and including the last block being pruned; andadjusting a monetary policy of the blockchain network so that theblockchain network will reintroduce the unspent tokens as tokensallocated in future blocks.
 2. The method of claim 1, wherein theunspent tokens are reintroduced back into the blockchain network in alater block through use of golden tickets.
 3. The method of claim 2,wherein the golden tickets are generated by one or more second nodesamong the plurality of nodes.
 4. The method of claim 3, wherein eachgolden ticket contains a computational puzzle.
 5. The method of claim 4,wherein tokens allocated through the use of golden tickets are splitbetween one or more third nodes among the plurality of nodes (“luckyminers”) that have provided solutions to the computational puzzles thatare contained in the golden tickets and one or more fourth nodes amongthe plurality of nodes (“lucky nodes”) that are selected by one or moreof the solutions to the computational puzzles.
 6. The method of claim 5,wherein distribution of the tokens split between lucky miners and luckynodes is determined by a paysplit variable managed according toconsensus rules of the blockchain.
 7. The method of claim 4, wherein adifficulty of each computational puzzle is determined using a difficultyvariable managed according to consensus rules of the blockchain.
 8. Anode among a plurality of nodes in a blockchain network, the nodecomprising: at least one processor; and a non-transitory computerreadable medium communicatively coupled to the at least one processor,the non-transitory computer readable medium having stored thereoncomputer software comprising a set of instructions that, when executedby the at least one processor, causes the node to: prune transactionslips in blocks in a blockchain preceding an arbitrary block identifiedaccording to consensus rules of the blockchain; calculate a value of allunspent tokens contained in all unpruned blocks preceding and includingthe last block being pruned; and adjust a monetary policy of theblockchain network so that the blockchain network will reintroduce theunspent tokens as tokens allocated in future blocks.
 9. The node ofclaim 8, wherein the unspent tokens are reintroduced back into theblockchain network in a later block through use of golden tickets. 10.The node of claim 9, wherein the golden tickets are generated by one ormore second nodes among the plurality of nodes.
 11. The node of claim10, wherein each golden ticket contains a computational puzzle.
 12. Thenode of claim 11, wherein tokens allocated through the use of goldentickets are split between one or more third nodes among the plurality ofnodes (“lucky miners”) that have provided solutions to the computationalpuzzles that are contained in the golden tickets and one or more fourthnodes among the plurality of nodes (“lucky nodes”) that are selected byone or more of the solutions to the computational puzzles.
 13. The nodeof claim 12, wherein distribution of the tokens split between luckyminers and lucky nodes is determined by a paysplit variable managedaccording to consensus rules of the blockchain.
 14. The node of claim11, wherein a difficulty of each computational puzzle is determinedusing a difficulty variable managed according to consensus rules of theblockchain.
 15. A system, comprising: a first node among a plurality ofnodes in a blockchain network, the first node comprising: at least onefirst processor; and a first non-transitory computer readable mediumcommunicatively coupled to the at least one processor, the firstnon-transitory computer readable medium having stored thereon computersoftware comprising a first set of instructions that, when executed bythe at least one first processor, causes the first node to: prunetransaction slips in blocks in a blockchain preceding an arbitrary blockidentified according to consensus rules of the blockchain; calculate avalue of all unspent tokens contained in all unpruned blocks precedingand including the last block being pruned; and adjust a monetary policyof the blockchain network so that the blockchain network willreintroduce the unspent tokens as tokens allocated in future blocks. 16.The system of claim 15, further comprising: a second node among theplurality of nodes in the blockchain network, the second nodecomprising: at least one second processor; and a second non-transitorycomputer readable medium communicatively coupled to the at least oneprocessor, the second non-transitory computer readable medium havingstored thereon computer software comprising a second set of instructionsthat, when executed by the at least one second processor, causes thesecond node to: generate one or more golden tickets; wherein the unspenttokens are reintroduced back into the blockchain network in a laterblock through use of the one or more generated golden tickets.
 17. Thesystem of claim 16, wherein each golden ticket contains a computationalpuzzle.
 18. The system of claim 17, wherein tokens allocated through theuse of golden tickets are split between one or more third nodes amongthe plurality of nodes (“lucky miners”) that have provided solutions tothe computational puzzles that are contained in the golden tickets andone or more fourth nodes among the plurality of nodes (“lucky nodes”)that are selected by one or more of the solutions to the computationalpuzzles.
 19. The system of claim 18, wherein distribution of the tokenssplit between lucky miners and lucky nodes is determined by a paysplitvariable managed according to consensus rules of the blockchain.
 20. Thesystem of claim 17, wherein a difficulty of each computational puzzle isdetermined using a difficulty variable managed according to consensusrules of the blockchain.